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

From: Stephen R. van den Berg <srb@cuci.nl>
Date: Sep 11, 2008, 19:55 UTC
Message-ID: <20080911195516.GE1451@cuci.nl>
In-Reply-To: <alpine.LFD.1.10.0809111534300.23787@xanadu.home>

Nicolas Pitre wrote:

>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> when doing things with temporary branches.  The origin field is meant to
>> be filled *ONLY* when cherry-picking from one permanent branch to
>> another permanent branch.  This is a *rare* operation.

Show 5 quoted lines

>... and therefore you might as well just have a separate file (which 
>might or might not be tracked by git like the .gitignore files are) 
>to keep that information?  Since this is a rare operation, modifying the 
>core database structure for this doesn't appear that appealing to most 
>so far.

For various reasons, the best alternate place would be at the trailing end of the free-form field. Using a separate structure causes (performance) problems (mostly).

>And, while recording this origin link is optional, you are likely to 
>make mistakes like forgotting to record it,

That is just as likely filling in the wrong commit message.

> or you might even wish to 
>fix it with better links after the facts.

That is not possible for commit messages, and should not be possible for origin links either (same reasons).

>  Having it versionned also 
>means that older git versions will be able to carry that information 
>even if they won't make any use of it, and that also solves the 
>cryptographic issue since that data is part of the top commit SHA1.

It would allow the data to be faked, that is undesirable for "git blame".

-- 
Sincerely,
           Stephen R. van den Berg.
"There are three types of people in the world;
 those who can count, and those who can't."