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

From: Linus Torvalds <torvalds@osdl.org>
Date: Apr 25, 2006, 15:21 UTC
Message-ID: <Pine.LNX.4.64.0604250811230.3701@g5.osdl.org>
In-Reply-To: <7v7j5e2jv7.fsf@assigned-by-dhcp.cox.net>

On Tue, 25 Apr 2006, Junio C Hamano wrote:

Show 9 quoted lines

> 
> How about an ability to "attach" arbitrary objects to commit
> objects?  The commit object would look like:
> 
>     tree 0aaa3fecff73ab428999cb9156f8abc075516abe
>     parent 5a6a8c0e012137a3f0059be40ec7b2f4aa614355
>     parent e1cbc46d12a0524fd5e710cbfaf3f178fc3da504
>     related a0e7d36193b96f552073558acf5fcc1f10528917 key
>     related 0032d548db56eac9ea09b4ba05843365f6325b85 cherrypick

This would at the face of it seem a bit better, but the fact is, it's not.

Without _semantics_ for the different cases, it's just random crud.

What does any of the fields _mean_ to git? In particular, if you cannot come up with an _exact_ definition of what they mean for fsck, pull, push, and any other random thing (how to show them for logging? How do they affect merge bases?), then it's still just random free-form text, and it should go into the random free-form section.

Show 7 quoted lines

> The semantics I would attach to these "related" links are as
> follows:
> 
>  * To the "core" level git, they do not mean anything other than
>    "you must to have these objects, and objects reachable from
>    them, if you are going to have this commit and claim your
>    repository is without missing objects".

Ok, a real semantic meaning. However:

THAT IS COMPLETELY USELESS.

It sure isn't useful for cherry-picking, which so far is one of the only "real examples" of where this would actually be used.

It isn't useful for much anything else either, because you really have two cases:

 - the "related" commit is an indirect parent _anyway_ (for things like 
   "revert", this would obviously be the case, since it doesn't generally 
   make a lot of sense to revert something that has never touched your 
   history). In this case, the git semantics end up being NULL, and you 
   just have another relationship that doesn't actually add any new 
   information to the tree.

 - the "related" commit is not actually in the set of _real_ parenthood at 
   all, and actually points to a different branch (or possibly even 
   different project).

   This case I'd sure as hell hate to have for the kernel, at least. I 
   would have to add crap to my workflow to make sure that people do _not_ 
   have these kinds of linkages that link in random parts of their project 
   that doesn't actually have anything to do with the history I'm pulling.

Those are the only two possible cases. Either it's an indirect parent, or it isn't. Neither one makes any sense: the first one is a no-op from your semantic definition, and the second one is just crazy and you'll just find that people have to protect themselves from other developers doing something crazy by mistake.

I want the git objects to have clear and unambiguous semantics. I want people to be able to explain exactly what the fields _mean_. No "this random field could be used this random way" crud, please.

			Linus