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