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

From: Theodore Tso <tytso@mit.edu>
Date: Sep 11, 2008, 21:01 UTC
Message-ID: <20080911210118.GO5082@mit.edu>
In-Reply-To: <20080911195516.GE1451@cuci.nl>

On Thu, Sep 11, 2008 at 09:55:16PM +0200, Stephen R. van den Berg wrote:

Show 6 quoted lines

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

Why would this matter? The information is largely self-authenticating. If a commit claims to have come from some other cherry-pick, a human taking a quick look at it would know instantly that this wasn't true. So what's the harm done if some incorrect information gets introduced? "git blame" is something which is generally used by humans, not by automated programs.

Also, what's the attack scenario? The person who originally makes the commit can easily fake the origin link information. They can hack git to fill on some other commit ID, for example. So what you are protecting against is someone after the fact adding the annotation that this commit was related to this other commit. When would this be a bad thing to do? If they are adding correct information, it's a good thing. If they add incorrect information, what's the harm they can as a result of being able to add the incorrect information. (Noting that if this annotation file is kept under git control, you can use what ever access controls and/or process controls that verify that a new cherry-pick --- or a commit claiming to be a cherry-pick --- is valid and should be accepted into the master git repository for that project.

						- Ted