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

From: Stephen R. van den Berg <srb@cuci.nl>
Date: Sep 11, 2008, 18:44 UTC
Message-ID: <20080911184405.GA1451@cuci.nl>
In-Reply-To: <alpine.LFD.1.10.0809111222170.23787@xanadu.home>

Nicolas Pitre wrote:

>On Thu, 11 Sep 2008, Stephen R. van den Berg wrote:
>> Let me try and describe once more the typical environment this origin field
>> is vital in:

>> Without the origin links, this workflow will cost a lot more time to
>> pursue (I know it, because I'm living it at the moment, and no, I'm not

>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.
- It should convey a sense of direction (it's a directed graph).

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

Show 6 quoted lines

>The semantics of a "may-be-related-to" link would be defined for object 
>reachability only:
>- If the may-be-related-to link is dangling then it is ignored.
>- If it is not dangling then usual reachability rules apply.
>That's all the core git might care about, and the only real argument for 
>not having this information in the free form commit message.

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.

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

>Still, in your case, you probably won't get rid of your stable branches,

True.

>hence the reachability argument is rather weak for your usage scenario,

Then again, I don't want to be bothered by stupid free-form origin links made to local branches by a developer. If the developer creates them using cherry-pick -o which creates an origin link, I'll never have to see his silly commit hashes where he is referring to commits in his local branch (and never waste time wondering where those commits are).

>meaning that you could as well have that info in the free form text 
>(like cherry-pick -x), and even generate a special graft file from that 
>locally for visualization/blame purposes.  Sure the indirection will add 
>some overhead, but I doubt it'll be measurable.

The free-form equivalent looks like:
Origin: df85f7855da44c730f942b330ada181209d09d7a ff1e8bfcd69e5e0ee1a3167e80ef75b611f72123
You need a pair of hashes, which is, a bit bulky, for my taste.

What special graft file would I need to visualise? Isn't having the origin link information enough?

Show 8 quoted lines

>People fetching your main branch won't have to carry the whole 
>repository because those weak links would otherwise be followed if 
>they're formally part of the commit header.  And if they want 
>to benefit from the information those weak links carry then they just 
>have to also fetch the branch(es) where those links are pointing.  At 
>that point it is trivial to regenerate the special graft file locally 
>which would also have the benefit of only containing links to actually 
>reachable commits, hence you'd never have dangling "origin" links.

You lost me here somewhere. Could you give a concrete example with one commit, one origin link (your style) and a special graftfile entry?

>Conclusion: the only fundamental reason for having this weak link 
>information in the commit header is for reachability convenience for 
>when the actual branch that contained the referenced commits is gone,

Erm. Quite the opposite, actually. The practical use for the origin link in case the target is unreachable is zero to none, so it can gleefully be ignored in that case. But maybe the semantics of your "related" link and my origin link are sufficiently distinct. For the arguments why it should be in the header of a commit, see above.

>which IMHO is a bad justification.  Having lines of developments hanging 
>off of a weak link alone is just plain stupid if you can't reach it via 
>proper branches or tags.

Agreed.  But this is in reference to your "related" link proposal.

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