Re: how to use git merge -s subtree?

On Sat, 05 Jan 2008 18:42:37 -0800
Junio C Hamano [off-list ref] wrote:

David Soria Parra [off-list ref] writes:

quoted

Well yes the history is preserved, but it's not connected to the
subdirectory. 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

The thing is, what you are talking is not about the subtree
merge strategy, but the fundamental philosophy of git.  Asking
for "the history of file B/foo.c" does not make any sense, as
git never tracks history of individual files.

Hi Junio,

Obviously you are making an important point here about the way Git is designed,
but I think you misspoke slightly.  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..

In a simple repo where you don't have any subtree merge, with a file /B/foo.c
that at some point earlier in the history was renamed from /foo.c, the command
"git log --follow B/foo.c" will show changes extending back before the rename.
However, that doesn't seem to work across a subtree merge.  Obviously there's
some technical reason for this that i'm overlooking, but on the surface the two
cases seem similar.

It would be nice to be able to do "gitk --follow git-gui.sh" in git.git and
actually see the history of that file.  As it stands now, you have to type
"gitk -- git-gui.sh ../git-gui.sh".  Is there a fundamental reason Git can't
be taught to notice this particular type of subtree merge "rename" and
support --follow type semantics?
 
At least the message you referenced from Linus leaves hope that this may be
possible as it makes the case that this is the type of thing that you can do if
you avoid locking yourself into inadequate rename-tracking data structures.

Sean