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

[Theodore Tso <tytso@MIT.EDU>]

On Thu, Sep 11, 2008 at 09:55:16PM +0200, Stephen R. van den Berg wrote:
> >  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