From: Junio C Hamano Date: Thu, 12 Jul 2007 08:31:44 GMT Subject: git-log --follow? Message-ID: <7vsl7uvx8v.fsf_-_@assigned-by-dhcp.cox.net> In-Reply-To: <7vzm22vyin.fsf@assigned-by-dhcp.cox.net> The message I am following up is a patch to unpack-trees.c, whose basic code structure is Daniel's work, so I wanted to CC him and the easiest way to look his address up was to run git-log on it. Not so. The "blame -C unpack-trees.c" output consists of this distribution of origin: 464 read-tree.c 337 unpack-trees.c 74 builtin-read-tree.c 11 tree.c 8 tree.h and most of the work by Daniel was done when the bulk of code was still in read-tree.c. Naturally the log output of unpack-trees.c does not have a single commit by him. "git log -- unpack-trees.c" would not follow into read-tree.c, but I thought "git log --follow -- unpack-trees.c" is supposed to; I tried it for the first time, but it does not seem to work as well as I hoped. I think this is just a testament that "following renames" is not as useful in a real project as people seem to believe, not a real complaint. When 16da134 created unpack-trees.c, it initially moved only very small part of builtin-read-tree.c to it. Later 076b0adc made further code movements from builtin-read-tree.c to unpack-trees.c. An interesting thing is that builtin-read-tree.c immediately before 16da134 is much similar to unpack-trees.c in 076b0adc than unpack-trees.c in 16da134, exactly because of this stepwise code movements. I do not think people can argue that "human user knows he is renaming the file so recording the human intention would have helped git a lot better" in this case, as the human user who made 16da134 did not even intend to do a rename.