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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html