On Tue, 21 Nov 2006, Yann Dirson wrote:
>
> I'm not sure I get the reason why the submodule should not be recorded
> on "commit level".
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".
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