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. Linus - : 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