On Wed, 9 May 2007, Linus Torvalds wrote:
>
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
