On Tue, Apr 08, 2008 at 07:42:08PM +0300, Teemu Likonen wrote: > I found something very strange in graphical history tools "gitk" and > "git log --graph" when used with --follow. In Git repository compare the > following: > > $ gitk -- utf8.c > $ gitk --follow -- utf8.c > > The output of "git log --graph" is somewhat similar: > > $ git log --graph --pretty=oneline -- utf8.c > $ git log --graph --pretty=oneline --follow -- utf8.c > > All I can say is that the output is not intuitive at _all_. Almost all > the commits are in separate history lines. Yes, I see this behavior too. The --follow option disables parent rewriting, which gitk and "git log --graph" both rely on in this instance. Without --follow, the revision list is first pruned, and then the parents are rewritten to include only those in the pruned list. The revision walk then occurs only over the pruned list. With --follow, the revision list is not pruned, so parent rewriting doesn't happen (and even if it did, I don't think it would have any effect, since all commits are still in the list). Instead, the revision walk traverses all commits, but the log-tree/diff code simply doesn't print any output for commits that aren't relevant. I'm not familiar enough with the diff code to know the best way to fix this. One possible way might be to perform an extra revision walk in revision.c before the "real" walk occurs. This initial walk would perform all of the diff calculations performed by the real walk, but only for the purpose of pruning the list. Then parent rewriting could be done, and the "real" revision walk would only walk over the pruned list. -- Adam Simpkins adam@xxxxxxxxxxxxxxxx -- 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
