Re: [RFC] [PATCH 0/5] Implement 'prior' commit object links

On Tue, 25 Apr 2006, Sam Vilain wrote:

I really don't think this is worth it.

We already have a very useful notion of "prior" commit that is used daily (well, weekly) for the Linux kernel, and it's used for one of the few places where this really makes unequivocal sense. "git revert".

It's also implemented in the only way that has clear and unambiguous semantics: by putting the prior link into the free-form part. The reason this is clear and unambiguous is that it makes it clear that it has no actual technical impact on any serious git strategy, ie there is never any question of "What does it _mean_?".

At the same time, it gives exactly what you actually _want_ for a prior link: it makes it easy to look up the commit that was replaced, or fixed, or that is related, or just any random semantics that you can explain easily in the text.

Both gitk and qgit already support it, and it's trivially cut-and-pasteable from any log message to see what it is when you work on the command line too.

In contrast, adding a new header is serious trouble:

 - What does it _mean_ from a technical angle? 

   Does it matter for merging? One of your patches seems to make it so, 
   which is _really_ confusing. Why should it? And does it affect anything 
   else that git does?

   Does "prior" have any meaning for "git-fsck-objects" and/or for object 
   pruning? For "git fetch/pull"?

 - What does it mean from a semantic standpoint?

   Is "prior" a note that something was reverted? Fixed? Changed? 
   Cherry-picked? And if it is Cherry-picked, than I would flat-out refuse 
   to ever merge with a tree that has it, because it pretty much by 
   definition means that the object that "prior" points to simply doesn't 
   _exist_ in my tree (since it was cherry-picked from somebody elses 
   tree). Or that it means that my history got tangled up with the history 
   of the failed branch that needed cherry-picking to clean up..

 - You say that there is just one "prior" parent, but why just one? 
   There's no way to even _think_ about this, since it seems to have no 
   actual semantic meaning.

I think all the problems really boil down to "What does this mean?"

Without an answer to that question, it's just a random feature. It's something that you can use and mis-use, but that has no "meaning". It only has whatever meaning you personally assign to it, but that implies that git shouldn't parse it, and shouldn't care about it.

Which again says that it should act like the current free-form thing does so well - it has no meaning, but it allows easy lookups.

		Linus