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

From: Jakub Narebski <jnareb@gmail.com>
Date: Sep 9, 2008, 23:59 UTC
Message-ID: <200809100159.59060.jnareb@gmail.com>
In-Reply-To: <alpine.LFD.1.10.0809091631250.3117@nehalem.linux-foundation.org>

Linus Torvalds wrote:

Show 19 quoted lines

> On Tue, 9 Sep 2008, Stephen R. van den Berg wrote:
>> Jakub Narebski wrote:
>>>"Stephen R. van den Berg" <srb@cuci.nl> writes:
>>>> The definition of the origin field reads as follows:
>> 
>>>> - There can be an arbitrary number of origin fields per commit.
>>>>   Typically there is going to be at most one origin field per commit.
>> 
>>> I understand that multiple origin fields occur if you do a squash
>>> merge, or if you cherry-pick multiple commits into single commit.
>>> For example:
>>> $ git cherry-pick -n <a1>
>>> $ git cherry-pick    <a2>
>>> $ git commit --amend        #; to correct commit message
>> 
>> Correct.
> 
> Quite frankly, recording the origins for _any_ of the above sounds like a 
> horribly mistake.

Actually the above is _not_ a good example for using 'origin', and why using 'origin'; just a bit convoluted example of multiple 'origin' headers.

> All those operations are commonly used (along with "git rebase -i") to 
> clean up history in order to show a nicer version.
> 
> The whole point of "origin" seems to be to _destroy_ that.

If I understand correctly the point is to record those 'origin' headers for git-revert (when 'origin'-ed commit is somewhere in the history), and for git-cherry-pick from other long lived branch and thus require additional option to git-cherry-pick to record 'origin' (denoting that you this is "true" cherry-pick, and not reordering of commits and cleaning up a history, better done with interactive rebase).

/me is playing advocatus diaboli here, 'cause I'm not that convinced to necessity of this feature.

-- 
Jakub Narebski
Poland