Re: [RFC] Applying a graft to a tree and "rippling" the changes through

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@osdl.org> writes:

> On Fri, 18 Nov 2005, sf wrote:
>> 
>> A commit is really just the statement: "I changed the tree from state A to
>> state B". After all, the commit message does not describe the new state
>> (neither the old state) but does describe the changes.
>
> There are lots of changelog entries that don't necessarily make sense 
> without knowing what went before them, so history is actually important 
> even in a local sense - it's often what allows the explanation to make 
> sense.

I agree with what you said about commit objects and what they
are meant to describe.  At the same time, I am sympathetic if
somebody wants to be able to say just "The change this commit
brings in can be used to modify the behaviour X to Y".  An
implied prerequisite for such a statement is that you can apply
such a change only to something that has behaviour X, and
internally works in a certain way to exhibit that behaviour, to
begin with (IOW, otherwise the patch does not apply).  While
your "commit describes all the history leading to it" obviously
satisfies that prerequisite, it is stronger than necessary.

For that matter, "tree A changed into tree B" is stronger than
necessary as well.  There are trees other than tree A that has
the same behaviour X, and applying such a change would be valid
to modify its behaviour to Y.

You are absolutely right that commit messages should be taken in
the context of the history leading to it.  However, when we
exchange patches via e-mail, or do "rebase" in the repository,
we also use the commit message to label the change -- and with
that usage, the log message becomes less about describing the
history and more about "modifies X to Y", so it is easy to get
confused.