Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links (and other commit links ideas)

From: Junio C Hamano <junkio@cox.net>
Date: Apr 25, 2006, 19:18 UTC
Message-ID: <7vslo1v4zw.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0604251155530.3701@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

Show 10 quoted lines

> And the rule is: git cares about the commit header, but not about the 
> free-form. Which means that anything it doesn't care about, it goes into 
> the free-form section, not into some "X-header" section.
>
> Whatever you build on TOP of git can have its own rules in that free-form 
> section. For example, the kernel project has this "X-header" thing called 
> the "sign-off", and git itself picked it up. There's even some support to 
> add it automatically to commits (the same way we add the "revert" info 
> automatically to commits), but nobody claims that git should "parse" that 
> information, or that it should be part of the "header".

Then we should drop the author header and make it part of free form text. The core does not give any meaning to it. And the name <email> part of the commit header as well. The only thing used by the core is the timestamp of the commit.

My initial 'related' without 'note' was flawed - it used cherry-pick as an example of 'related' when it clearly should have been 'note' (no connectivitiy required).

Having said what I wanted to say about 'note', let's clarify what I have in mind about the 'related' that _means_ connectivity. As I said, I am far less convinced it is a good thing than I am about 'note' by now, but just for the sake of completeness of the discussion.

I tend to agree with you that ability to misuse 'related' (I'd call it 'link' to make it clear that it means connectivity) to fetch/push "related" objects, with an unclear definition of related-ness, is a bad thing. Even if we fetched the objects that are claimed to be related to the main project, if we do not know what to do with them, it is not useful.

And for well defined connectivity, we could give separate names, just like we have 'tree' and 'parent' in the commit header. That's how "bind commit" was initially proposed. It was not 'link bind'.

The suggestion of 'link bind' came primarily from the pain I experienced when I taught rev-list --objects and fsck-objects about it in the jc/bind branch. If the only thing asked to the core by 'link' is to make sure the related objects are made available, and Porcelains take responsibility after they are made available, we would be better off teaching the commit parser how to parse 'link' (regardless of its nature of linkage) and teach rev-list --objects and fsck-objects to do connectivity just once, rather than adding 'bind' now and then having to do the same backward incompatible change when adding something else that requires connectivity.

There definitely needs to be an ability to specify a list of "nature of links this repository accepts", if we were to do 'link'. It probably should default to an empty set. rev-list --objects would include objects pointed by 'link' only when the repository wants such links to be honored. fsck-objects will declare an object that is reachable only by a 'link' that is not accepted by the repository "uninteresting" and let git-prune remove it.