Re: git log --follow doesn't follow a rename over a merge

[Jeff King <peff@peff.net>]

On Thu, Jun 16, 2011 at 06:01:25PM +0100, James Blackburn wrote:

> I see a lot of this has been discussed before... but just to add that
> Jeff's blame-log.sh:
> http://git.661346.n2.nabble.com/alternate-log-follow-idea-td1385917.html
> seems to work and show the full history of the file past the rename+merge!

You may want to also check out the "line-level history browser" work by
Bo Yang and Thomas Rast, which is a similar idea, but done much better.

You can find it here:

  http://repo.or.cz/w/git/trast.git/shortlog/refs/heads/line-log-cleanup

or pull it with:

  git pull git://repo.or.cz/git/trast.git line-log-cleanup

Use on a whole file is something like:

  git log -L '1,$':yourfile

But note that it is a work in progress, and I seem to be able to get it
to segfault on some simple tests.

> I was also interested in whether there's a better way of re-connecting
> history than grafting one repository's history into the commit which
> made it visible in another?  AFAICS the graft is no different to a
> merge commit which contains a rename in the merged node, so I'm
> guessing this is a reasonable thing to do?

Usually you would graft the tip of the old history to the root commit of
the new history. So it's not a merge, but makes it look like a
contiguous linear history near the graft. But that's only a
per-repository thing. If you want to join two histories in the actual
history graph, you would merge them; if one supersedes the other, then
you would use the "ours" merge strategy to ignore the other side.

I'm not 100% sure I understand your question. Does that answer make
sense?

-Peff