On Tue, Apr 08, 2008 at 07:42:08PM +0300, Teemu Likonen wrote:
quoted text
> 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@adamsimpkins.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html