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

From: sean <seanlkml@sympatico.ca>
Date: Apr 25, 2006, 18:45 UTC
Message-ID: <BAYC1-PASMTP03E0B5376ACFF165B29ED1AEBF0@CEZ.ICE>
In-Reply-To: <Pine.LNX.4.64.0604251125010.3701@g5.osdl.org>

On Tue, 25 Apr 2006 11:26:25 -0700 (PDT) Linus Torvalds <torvalds@osdl.org> wrote:

Show 9 quoted lines

> It can't help porcelain.
> 
> If we have undefined or bad semantics for it, the only thing it can do is 
> _hurt_ porcelain, because it will cause confusion down the line.
> 
> Semantics for data objects are _the_ most important part of a SCM. Pretty 
> much any project, in fact. 
> 
> And bad or weakly defined semantics will invariably cause problems later.

Take your example of how git-revert works today, it copies the comment from 
the original, thus keeping this semantic-free meta-data intact between
related commits.  However, you'd have to jump through hoops to accomplish
this same simple task with any third party meta data, unless it was 
burried inside the commit message text.

> So why argue for it?
> 
> Just use the existing comment field.

The last argument you and I had was me taking the other side, saying that it was fine for git to parse the free form text area to extract information; you rightfully showed me why that was wrong.

It's no different for a bug tracker or other 3rd party software that wants to interface with git, it's bad design to force them to parse a single free form text comment into individual pieces to extract their meta data. Especially when git could easily add the ability to add multple comments to each commit.

Sean