Re: [RFC] Second parent for reverts

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 10, 2007, 16:35 UTC
Message-ID: <alpine.LFD.0.98.0705100927340.3986@woody.linux-foundation.org>
In-Reply-To: <alpine.LFD.0.98.0705091513050.4062@woody.linux-foundation.org>

On Wed, 9 May 2007, Linus Torvalds wrote:

Show 8 quoted lines

> 
> If you want a "related to that commit" field, it should be a separate 
> field in the commit object. But since it doesn't really have any real 
> *semantic* meaning to git itself, it shouldn't be in the header. We 
> could, for example, make it be in the free-form section, and teach our 
> graphical visualization tools to automatically turn it into a hyperlink.
> 
> .. which we already do.

Btw, sorry for harping on this issue, but one of the really *great* things about putting things in the free-form section is a somewhat unanticipated huge advantage:

 - we've had much better integration with non-git users than any other SCM 
   I've ever seen!

Now, a lot of that was by design (ie one of the primary design goals for git was to work well with patches), and it's one of the reasons that I totally dismiss the whole "track file ID's" idiocy: anything but "content" will pretty much by definition not be tracked by any other source control system.

But it turns out that the whole "you can point to commits in the free-form commit message" thing has worked out really well. It means, for example, that people can do "git revert" operations in their own local repository, AND THEY TRANSLATE BEAUTIFULLY EVEN AS EMAILED PATCHES!

I'm shouting, because it's easy to overlook these kinds of issues, but they are really really important. Designing your SCM around the notion that everybody will use a totally integrated system is a mistake! It's a *huge* mistake. Even a lot of git users end up sending patches back and forth, just because for many things it's actually more appropriate.

So I'm literally getting patches that refer to commits that I've integrated ("Commit xyz introduced a nasty bug", or "Revert commit abc") and they work very well even when I'm not merging with those people natively through git.

And yes, maybe the kernel is a bit unusual in this, but I really don't think it should be. In many ways, emailing patches around is a much better workflow for actual *development* than doing git merges. The git merges are wonderful, but they are kind of a "the development is done, let's merge it" operation - they are not good for sending stuff out for comments or discussion!

So in general, putting things into the headers and having git semantic meaning should be discouraged. The "parents" thing is special, because the whole "history" thing is very deeply integrated in git, and obviously has to be (any SCM that does _not_ have parenthood information is totally broken *cough*CVS/SVN*cough*), but other than that we should actually strive to _avoid_ anything with deep git semantics.

		Linus