Re: Git log follow question

From: Jeff King <peff@peff.net>
Date: May 26, 2010, 05:58 UTC
Message-ID: <20100526055823.GA30409@coredump.intra.peff.net>
In-Reply-To: <alpine.LFD.2.00.1005251141580.3689@i5.linux-foundation.org>

On Tue, May 25, 2010 at 11:49:25AM -0700, Linus Torvalds wrote:

Show 9 quoted lines

> On Tue, 25 May 2010, Jeff King wrote:
> > 
> > Thanks for the input. I took a look at it myself and it is a bit more
> > complex than just turning on pruning. I have a prototype --follow that
> > handles arbitrary pathspecs instead of single files; instead of
> > replacing the single-file pathspec, it just widens the pathspec as it
> > traverses history.
> 
> Doing it "right" is actually a _lot_ more complex than that.

Did you mean doing history rewriting right is more complex than that, or did you mean that handling multiple follow pathspecs is more complex than pathspec-widening (where "handling multiple pathspecs" means making "--follow subdir" work about as well as "--follow file", but not actually doing real history rewriting)?

If the former, I agree.

If the latter, I am not sure it is any worse than the single-file follow case.

For example, consider this history:

  echo content >file && git add . && git commit -m base
  git mv file new && git commit -m moved
  sleep 1 ;# to ensure timestamp difference
  git checkout -b other HEAD^
  echo changes >>file && git commit -a -m changes
  git merge master

We'll traverse in this order:

  merge
  changes (to file)
  moved (from file to new)
  base (create file)

If I do "git log --follow new" with the current master, I will see only "moved" and "base". I don't see "changes" because it operates on "file", not "new". But if we reverse the order in which the two branches' commits were made, then we will parse "moved" first, and we _will_ see "changes", because we've updated our pathspec. So it matters when we traverse the rename.

For "base" and everything prior to it, in general we will already have traversed the rename because we try to do things in date order. But in the face of clock skew, it is possible to follow the ancestry down before hitting a rename on another branch.

So my point is that even with the current --follow, there are already corner cases where traversal order matters. Which is maybe the point you were trying to make, too, but I was unclear from your example if you meant that the problem was _worse_ with simple expansion of pathspecs (i.e., not actually turning on revs->prune) than the current --follow.

-Peff