Re: gsoc - Better git log --follow support

[Jeff King <peff@peff.net>]

On Wed, Mar 23, 2011 at 12:23:45AM +0100, Michał Łowicki wrote:

> >  # But now look at it in gitk. Commit 4 is included as a boundary
> >  # commit, but we fail to notice that it connects to three. And we
> >  # don't see commit 3 connecting to anything, and commit 1 is missing
> >  # entirely.
> >  gitk --follow newfile
> 
> Why commit 4 is displayed here (changes only file2) ?

It's part of how gitk shows the graph. It shows all of the commits you
asked for with blue nodes, and then it shows the "boundary" commits with
a special white node. This lets you distinguish between actual root
commits (i.e., ones with no parents) and ones whose parents are simply
uninteresting to the current query.

> # git log with graph works here OK. It displays six -- five .. --
> three .. - one .In this case results shouldn't be similar to gitk ?
> git log --graph --follow newfile

Sort of. Notice the "..." in the output (it is easier to see with "git
log --graph --oneline --follow newfile). It is not showing the
simplified history, but instead indicates that there were some commits
omitted in between the two points. It doesn't make the output terrible
in such a simple linear case. But consider a case with branching:

  # Our A-B-C repo
  git init repo && cd repo
  echo content >file1 && git add file1 && git commit -m one
  echo content >file2 && git add file2 && git commit -m two
  echo content >>file1 && git add file1 && git commit -m three

  # Now make a side branch that also touches file1
  git checkout -b side HEAD^
  echo content >>file1 && git commit -a -m four

  # And merge them back to together
  git merge master

  # And then do our other commits with rename on top
  echo content >>file2 && git commit -a -m five
  git mv file1 newfile && git commit -m six
  echo content >>newfile && git commit -a -m seven

Showing "git log --graph --oneline --follow newfile" becomes a bit more
confusing. A simplified history would show "six" as the merge between
the two branches, but here it happens at some indeterminate point in the
history that is not shown.

And again, this is a simple example. For something more complex, try
this in git.git:

  # We know builtin-add.c got renamed to builtin/add.c, so
  # let's cheat and tell git which paths we're interested in.
  # The resulting graph is pretty readable, and is more or less what we
  # would want from --follow.
  git log --oneline --graph -- builtin-add.c builtin/add.c

  # Now try it with --follow. Not so pretty.
  git log --oneline --graph --follow builtin/add.c

-Peff