Thread (5 messages) flat view 5 messages, 3 authors, 2016-06-15

git-log --follow?

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:43:20

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help