Re: gsoc - Better git log --follow support

From: Jeff King <peff@peff.net>
Date: Mar 23, 2011, 16:20 UTC
Message-ID: <20110323162023.GC30337@sigill.intra.peff.net>
In-Reply-To: <AANLkTi=woLeveur6gKnSXTRzmS8nB0o4M9HegJ+GNUCa@mail.gmail.com>

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

Show 7 quoted lines

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