Re: [RFC] Submodules in GIT

On Tue, 21 Nov 2006, Yann Dirson wrote:

Because that would be STUPID.

What does the submodules have to do with the commit level? Nothing. Nada. Zero.

Submodules are _directories_. They can be anywhere in the directory tree. If you try to encode that in a commit message, you're going to totally break the whole notion of trying to "diff" two trees.

All of git is designed around the notion that a tree is the directory structure. If you put directory structure somewhere else, you totally screw all abstractions.

Now, if that weren't enough, let me enumerate _another_ reason why it's idiotic and wrong, namely the fact that a "commit" is fundamnetally the wrong place to add something like that _anyway_. Quite apart from the fact that we describe directory trees with (wait for it): "tree objects", the thing is, a commit is about a totally different _dimension_ altogether.

The only and _whole_ point of a "commit" is to describe the "time dimension". Something that doesn't always change in time should not be in a commit object, because it is by definition not what a commit is all about. A commit should describe the relationship of itself to other commits, ie it's a "how did this change".

And a sub-project simply doesn't even _do_ that. Much of the time, a subproject stays constant, and is not something that comes and goes on an individual commit basis.

I don't understand why people are so fixated with putting things in the wrong object. WHY do people want to put crap in the "commit" object? People have wanted to put "rename" information there (which is stupid for all the same reasons: renames _remain_. They aren't a one-time event. If something was renamed in commit X, it will _remain_ renamed in commit X+1, so it's clearly not really a "commit X" thing)

Think of it this way:

 - if something _only_ makes sense on an _individual commit_ level, it 
   goes into the "commit object". But if it makes sense for "git diff",
   then it MUST NOT be in a commit object, because you do "git diff" over
   a big _range_ of commit objects.

Think "git show". The "author" of a commit is only associated with a _single_ commit. It thus goes into the commit object, and nowhere else. Same goes for time, and commit message. A commit message is fundamentally a "this explains this _one_ commit".

But anything that you expect to have in a "range" of commits MUST NOT be in a "commit object". If I do "git diff v2.6.13..v2.6.14", and I expect the behaviour you want to encode to show up (and dammit, subprojects very much fall under that heading - exactly the same way renames must have meaning _outside_ of a single commit) then clearly it is NOT something that is associated with any individual commits. It's something that is associated with the _state_ of the project.

And the _state_ of the project is the "tree". Not the commit. The commit is about the _history_ of the project.

So please understand this: "commit" is about the time-dimension ("history"). "tree" is about the space-dimension ("state"). The two are _related_, but they are also very much different concepts, and "related" does not mean "you can mix them up".

Sub-projects are clearly not about "time". They are about "state".