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

[Nicolas Pitre <nico@cam.org>]

On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:

> So short-circuiting the reasoning suggests that since the only thing
> that actually changes now is the position of the field (at the top or
> end of the commit message), we might as well do it right and put it in
> the top, that gets rid of the two minuses.
> 
> Anything I missed?

A good convincing demonstration that this is actually worth doing in the 
first place.  And here I'm talking about the _feature_ and not the 
_implementation_.

> Basically it means that:
> 
> a. If there is a better solution to tracking the backports, I'll gladly
>    use that instead, but simply using the current really freeform
>    approach doesn't cut it (it currently refers to a single commit,
>    instead of a pair of commits, and takes too long to parse out in a
>    --top-order or blame command).  Better solutions I haven't heard so
>    far.
> 
> b. I need the integrity protection of a commit to make sure that the
>    origin fields cannot be altered later; blame would be too easy to fool
>    otherwise.  So using the notes solution seems to be out (it would also
>    be quite a performance hit again).
> 
> c. I consider the Origin: field at the end of the commit message a
>    workable solution, but it smells like X-header-extension-messes as in
>    E-mail headers, and it incurs a small performance hit (in case of
>    --topo-order/blame/prune/fsck), but maybe this performance hit can be
>    minimised by making sure that the fields are *always* at the end
>    of the commit message.
> 
> d. Using the proposed origin header in the standard commit header has
>    close to zero overhead (in most commits the field is not present), yet
>    codecomplexitywise it is almost identical with the Origin: field at
>    the end of the commit message.
> 
> I find it remarkable though that people are dragging their feet at
> solution d, yet are quite ok with solution c.  IMO solution c and d are
> almost identical, except that solution c is ugly, and solution d is
> elegant.  But if it makes it easier to prove the usefulness by
> implementing the ugly solution first, that's fine.

Technically speaking, implementation d is obviously the most efficient.  
but, as mentioned above, the actual need for this feature has not been 
convincing so far.  Until then, it is not wise to add random stuff to 
the very structure of a commit object, while c can be done even 
externally from git which is a good way to demonstrate and convince 
people about the usefulness of such feature.


Nicolas