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

From: Jakub Narebski <jnareb@gmail.com>
Date: Apr 25, 2006, 17:36 UTC
Message-ID: <e2lmm3$rts$1@sea.gmane.org>
In-Reply-To: <Pine.LNX.4.64.0604251004410.3701@g5.osdl.org>

Linus Torvalds wrote:

Show 7 quoted lines

> On Tue, 25 Apr 2006, Jakub Narebski wrote:
>> 
>> The generic commit links "related" which is fsck-able at least and "note"
>> which is not. It is idea somewhat on the level of providing _extended
>> attributes_ in VFS in Linux kernel, IMVHO.
> 
> And nobody actually uses extended attributes either, do they?

Fedora's SELinux does use them, IIRC.

Well, people do use X-* headers in mail (sean's example), and some of them got promoted from X-* to ordinary mail header status.

> Plus it's _not_ fsck'able, since the thing doesn't even have any valid
> semantics. You guys can't even agree on whether the object must exist or
> not.

Erm, further on we did agree 
  http://permalink.gmane.org/gmane.comp.version-control.git/19142
  (Message-Id: <7vmzeax9gj.fsf@assigned-by-dhcp.cox.net>). 
"related" links means that object must exist. "note" is what name says, just
note and doesn't even need to point to object.

Show 6 quoted lines

> For exactly the same reason, git should not track it when a developer says
> "I think this commit is related to that commit". It's not hard data, that
> has hard and clear semantics.
> 
> Once you start adding data that has no clear semantics, you're screwed. At
> that point, it's a "track guesses" game, not a "track contents" game.

Well, the best example, i.e. remembering cherry picking has well defined semantic (added when cherry-picking, used when merging, object does need not to exist) but not well defined form. Currently the convention for free-form is used, which has its advantages and disadvantages as pointed out by Junio.

[somewhat unrelated note]

> Git tracks contents, and the well-defined history of how those contents
> came to be. Git does NOT track "additional notes" left by the developer
> that have weak semantics. Git does not track when a developer says "I
> renamed a file".

But I'd like Git to remember when I corrected false positives in "rename" detection during merge, and added undetected automatically renames/file contents copying and/or moving. Whether it would be done by saving the information in commit header, commit free-for, or somewhere else...

-- 
Jakub Narebski
Warsaw, Poland