On Sat, 05 Jan 2008 18:42:37 -0800 Junio C Hamano <gitster@xxxxxxxxx> wrote: > David Soria Parra <sn_@xxxxxxx> writes: > > > 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 - 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
