On Tue, 25 Apr 2006 08:40:25 -0700 (PDT) Linus Torvalds <torvalds@xxxxxxxx> wrote: > On Tue, 25 Apr 2006, Linus Torvalds wrote: > > > > I want the git objects to have clear and unambiguous semantics. I want > > people to be able to explain exactly what the fields _mean_. No "this > > random field could be used this random way" crud, please. > > Btw, if the whole point is a "leave random porcelain a field that they can > use any way they want", then I say "Hell NO!". > > Random porcelain can already just maintain their own lists of "related" > stuff, any way they want: you can keep it in a file in ".git/porcelain", > called "list-commit-relationships", or you could use a git blob for it and > have a reference to it in .git/refs/porcelain/relationships or whatever. > > If it has no clear and real semantic meaning for core git, then it > shouldn't be in the core git objects. > > The absolute last thing we want is a "random out" that starts to mean > different things to different people, groups and porcelains. > > That's just crazy, and it's how you end up with a backwards compatibility > mess five years from now that is totally unresolvable, because different > projects end up having different meanings or uses for the fields, so > converting the database (if we ever find a better format, or somebody > notices that SHA1 can be broken by a five-year-old-with-a-crayon). > > There's a reason "minimalist" actually ends up _working_. I'll take a UNIX > "system calls have meanings" approach over a Windows "there's fifteen > different flavors of 'open()', and we also support magic filenames with > specific meaning" kind of thing. > It's a fair point. But adding a separate database to augment the core information has some downsides. That is, that information isn't pulled, cloned, or pushed automatically; it doesn't get to ride for free on top of the core. Accommodating extra git headers (or "note"'s in Junio's example) would allow a developer to record the fact that he is integrating a patch taken from a commit in the devel branch and backporting it to the release branch. Either by adding a note that references the bug tracking #, or a commit sha1 from the devel branch that is already associated with the bug. Of course that information could be embedded in the free text area, but you yourself have argued vigorously that it is brain damaged to try and rely on parsing free form text for these types of situations. Most of the potential uses aren't really meant for a human to read while looking at the log anyway, they just get in the way. Another option that you alluded to, was to stuff the information in another git object. But such an object would have to embed a reference to the original commit, thus you haven't really made changing the SHA1 algorithm any easier. And then you also then have to jump through hoops to make sure that you pull the proper extra blobs that contain information about the real commits you just pulled. But if the information is in the actual commit header it gets to tag along for free with never any worry it will be separated from the commit in question. So when the developer above updates his official repo the bug tracker system can notice that the bug referenced in its system has had a patch backported and take whatever action is desired. Of course there are other ways to do this, but integrating it into git means it gets a free ride on the core, and it shouldn't really get in the way of core any more than email X- headers get in the way of email flowing. Sean - : 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