Subject: Re: [RFC] origin link for cherry-pick and revert

From: Jakub Narebski <[email-masked]>
Date: Thu, 11 Sep 2008 18:53:52 +0200

Linus Torvalds wrote:
> On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
> 
>> If you fetch just branches A, B and C, but not D, the origin link from A
>> to D is dangling.  Once you have fetched D as well [..]
> 
> So I just said we deleted beanch 'D', so there's no way to ever fetch it 
> again.
> 
> Get it?
> 
> The fact is, a big part of git is temporary branches. It's one of the 
> *best* features of git. Throw-away stuff. Those throw-away branches are 
> often done for initial development, and then the final result is often a 
> cleaned-up version. Often using rebase or cherry-picking or any number of 
> things.
> 
> And this is why "git cherry-pick" DOES NOT PUT THE ORIGINAL SHA1 IN THE 
> COMMENT FIELD BY DEFAULT.
> 
> (Although you can use "-x" to make it do so for when you actually _want_ 
> to say "cherry-picked from xyzzy")

And that is why the proposal was to use "-o" option to git-cherry-pick
to add 'origin'/'changeset' header, exactly because git-cherry-pick is
_abused_ to clean up branches and reorder commits; although I think that
"git rebase --interactive" (and patch management interfaces) do replace
using git-cherry-pick for that purpose.

git-revert would add 'origin'/'changeset' header unconditionally,
just like by default it seeds commit message with SHA-1 id of reverted
commit.

> Can you not understand that? The "origin" field is _garbage_. It's garbage 
> for all normal cases. The original commit will not ever even EXIST in the 
> result, because it has long since been thrown away and will never exist 
> anywhere else.
> 
> Garbage should be _avoided_, not added.

Hmmm... the difference between having 'origin' in a commit object header,
and having it in commit mesage is like difference between 'Signed-off-by:'
convention and 'author' header.  First is the matter of workflow, second
is inherent, required and non-avoidable part of revision information.

On the other hand git-cherry and git-blame would then have rely on
parsing correctly free-form part of a commit object, to take advantage
of 'origin' information: something what 'origin' info is for.

P.S. 'generation' header was not added... just saying... :-)

-- 
Jakub Narebski
Poland