Re: how to use git merge -s subtree?

[Junio C Hamano <gitster@pobox.com>]

Sean <seanlkml@sympatico.ca> 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:

>> ... 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?