Sean [off-list ref] writes:
... Asking for the history of a file does make
sense. Through path limiting you can ask to see just the subset of history that
touched a certain file or directory etc..
That's asking for the history of a _path_ (or subset defined by
paths, as in "what changes were made to paths under 'arch/'"),
which is very different from asking "I have B/foo.c -- show me
the history of that _file_".
Remember, David stated:
quoted
... So you cannot do git-log B/foo.c as git doesnot know where
to search it as it thinks it is in /foo.c not in B/foo.c ...
Notice "as git does not know where to search it" part?
Think --- what does that "it" refer to in that sentence?
The statement is not about paths. If it were about paths, then
the output of "git log B/foo.c" does show what he wants. The
question "git log B/foo.c" asks is "what change were made to the
path at B/foo.c". The changes made to B/foo.c (i.e. what's
shown with the diff headers that begin with "--- a/B/foo.c") are
shown. The changes made to foo.c are not shown.
But that is different from what David is asking. He wants to
know what changes were made to B/foo.c or to foo.c, and wants to
make the choice between the two depend on commit. The reason
you think you can pick between foo.c and B/foo.c is because
there is an illusion that somehow there is an i-node like file
identity that is kept track of, and it is preserved across
renames and merges.
That's keeping track of the history of a _file_.
And as you know, git doesn't do that.
What git does is to keep track of the history of the whole tree,
but prune the parts that are not interesting away when you view
the history. And the pruning can be specified by _PATH_.
See the difference?
On Mon, 07 Jan 2008 13:04:34 -0800
Junio C Hamano [off-list ref] wrote:
That's asking for the history of a _path_ (or subset defined by
paths, as in "what changes were made to paths under 'arch/'"),
which is very different from asking "I have B/foo.c -- show me
the history of that _file_".
Remember, David stated:
quoted
quoted
... So you cannot do git-log B/foo.c as git doesnot know where
to search it as it thinks it is in /foo.c not in B/foo.c ...
Notice "as git does not know where to search it" part?
Think --- what does that "it" refer to in that sentence?
The statement is not about paths. If it were about paths, then
the output of "git log B/foo.c" does show what he wants. The
question "git log B/foo.c" asks is "what change were made to the
path at B/foo.c". The changes made to B/foo.c (i.e. what's
shown with the diff headers that begin with "--- a/B/foo.c") are
shown. The changes made to foo.c are not shown.
But that is different from what David is asking. He wants to
know what changes were made to B/foo.c or to foo.c, and wants to
make the choice between the two depend on commit. The reason
you think you can pick between foo.c and B/foo.c is because
there is an illusion that somehow there is an i-node like file
identity that is kept track of, and it is preserved across
renames and merges.
That's keeping track of the history of a _file_.
And as you know, git doesn't do that.
What git does is to keep track of the history of the whole tree,
but prune the parts that are not interesting away when you view
the history. And the pruning can be specified by _PATH_.
See the difference?
Junio,
Thanks for taking the time to answer, I know you're busy with much more
pressing issues getting 1.5.4 out the door. You make the distinction
between paths and files quite clear, and why it's important to keep in
mind.
In the case of the "--follow" option though, the user might be forgiven
for thinking in terms of files rather than paths. Even the git-log
documentation says for "--follow", "Continue listing the history of a
file beyond renames". Which at least implies that Git knows about
file history, rather than just paths.
It's reasonable for a user to expect "git log --follow B/foo.c" to do
The-Right-Thing in the subtree merge case. But I recognize that it would
actually be rather difficult to implement, perhaps making it impractical.
Cheers,
Sean