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

From: Jeff King <peff@peff.net>
Date: Jun 16, 2011, 17:45 UTC
Message-ID: <20110616174554.GC6584@sigill.intra.peff.net>
In-Reply-To: <BANLkTi=4S08h=uMV5oo7S9qpruMot2kVfg@mail.gmail.com>

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.

Show 5 quoted lines

> 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