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

From: Jakub Narebski <jnareb@gmail.com>
Date: Sep 11, 2008, 16:53 UTC
Message-ID: <200809111853.53065.jnareb@gmail.com>
In-Reply-To: <alpine.LFD.1.10.0809110835070.3384@nehalem.linux-foundation.org>

Linus Torvalds wrote:

Show 21 quoted lines

> 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.

Show 6 quoted lines

> 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