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