Re: Git log follow question

[Jeff King <peff@peff.net>]

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

> 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