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:

> Nicolas Pitre wrote:
> >First, its name.  The word "origin" probably has a too narrow meaning 
> >that creates confusion.  I'd suggest something like a 
> >"may-be-related-to" field that would be like a weak link.
> 
> Well, the important properties of the name/field would be:
> - It should be as specific as possible, in order to minimise the
>   potential for abuse in the future.  I distill the desirability of this
>   requirement out of the various earlier discussions about commitheaders
>   in the past on this mailinglist held by others.

Well, sure.  But being too specific sometimes limits its usefulness.  
There could be other usages for such a link which IMHO should be defined 
in terms of graph connectivity semantics rather than high level purpose.

> - It should convey a sense of direction (it's a directed graph).

Well, isn't that already obvious?

> Any generic may-be-related-to field is therefore probably a non-starter.

Well, my whole argument is that if it has no generic purpose then it 
probably doesn't belong in the commit header.

> The origin field as currently proposed tightens the requirements that
> it either is dangling and ignored or points to a commit.
> rev-list --topo-order should use the origin links to order the output.
> gc/prune won't delete commits referenced *by* an origin link.

And I disagree on the gc/prune point, as mentioned previously.

As to rev-list --topo-order, it doesn't need for this link to actually 
be part of the commit object to accomplish the desired effect.

> The only two other arguments one might give to actually keep the field
> in the header of the commit as opposed to the trailer is that the 
> physical field can be kept machine readable, and the actual display can be
> beautified like:  Origin: 2abcdef..1234567
> The output of the field could be suppressed (if so desired) if the
> target commit isn't reachable.
> All this is of course possible for a trailer field in the free-form
> area as well, but it seems a bit silly to have two places for "headers".

And I think you should simply create a file within the repository with 
that info instead of either thecommit header or the free form text.  It 
gives all the usability advantages you wish for and more.


Nicolas