On Wed, 26 May 2010, Jeff King wrote: > > > > Doing it "right" is actually a _lot_ more complex than that. > > Did you mean doing history rewriting right is more complex than that, History rewriting with changing pathspecs. > or did you mean that handling multiple follow pathspecs is more complex > than pathspec-widening No, the "expand pathspec to cover the newly found rename" part is pretty simple. But the fact that the pathspec changes over the history inevitably leads to the problem of finding commits in the right order. The thing is, if the pathspec is history-dependent, then that means that in order to get it right, you should walk the history in topological order in order to get a proper pathspec. But you don't know what the topological order _is_ until you've walked the history - which in turn means that if you want to get "perfect" results, you need to walk the history first, and then have a separate phase to do the pathspec. That's actually what the current --follow kind of does, but because the current follow isn't even trying to get a proper pathspec in the bigger picture (it only tracks a single global filename rather than widening the net), it also skips the topological part, since even if it did things in topological order it would _still_ get things wrong. Doing it really right also actually would require making the pathspec be a per-commit thing rather than a single global one. Otherwise you get other odd effects, if that filename has ever been something different. But since you only do a simple widening, I guess you don't much care (you already get odd effects if there was a criss-cross rename, and will end up picking up the history for _both_ files, rather than just the original one). Linus -- 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