On Sun, 11 Jun 2006, Marco Costalba wrote: > > Why I still get empty results if I run git-rev-list from gitweb merge point? Because the rename happened _inside_ the merge. So when you give the revision 0a8f4f00, that really means the state _after_ the merge. At that point, the filename doesn't actually exist. git-rev-list then looks at the parents, one by one, and sees that the first parent _matches_ the state as far as your path spec is concerned (in this case, it matches "it was empty before, it was empty after"), so it will literally _always_ pick the parent that you're not interested in (regardless of whether it would have been merged into, or was the one that got merged), because that's the one with the minimal history difference. Going the other way (the way you actually wish it went) would have introduced more history changes that aren't needed to explain the final state, so git-rev-list - by virtue of trying to generate a _minimal_ history - will actively avoid it. > Is this because path changed: gitweb.cgi -> gitweb/gitweb.cgi Well, in one sense yes, but in a much more fundamental sense that rename really has nothing to do with the real issue. The real issue is that you asked how the state of a non-existent file came to be, and git-rev-list told you the simplest answer: it never existed at all. And that answer is actually _true_. Along one history, that filename never existed. And this really has nothing to do with renames. You can see the exact same thing with files that are there. Let's take an example: A <-- top of tree / \ B C | | D E \ / F | . <-- old history . Let's say that you have had a file called "file" for all of history, and it got changed sligtly differently in _all_ commits B, C, D _and_ E. Now, despite all the different changes, let's say that the end result was identical in B and C - even though the diffs of those two commits were not necessarily the same (because they started out from different points: D and E respectively). In other words, there was a branch, but both branches ended up fixing the same bug the same way (and this is less unusual than you'd think, even if they are independent, but even more so if the branches "knew of each other" some other way, ie the developers talked about the problem and perhaps sent patches back-and-forth that both people applied). What do you think git-rev-list will do when you give it that "file" as a path limiter? What it will do is to notice that merge A has the same state (wrt that file) as commit B (it's first parent), SO IT WILL TOTALLY IGNORE THE WHOLE HISTORY THAT IS REACHABLE FROM C. So git-rev-list will first simplify the tree to just A -> B -> D -> F .., and then, since A and B were identical in the path (and let's say F was identical to it's parents too), it will actually decide that as far as those commits were concerned, nothing changed, so the actual end result is just "B -> D -> ...", and none of A, C, E and F show up at all, even though both C and E really did change something (they just didn't _matter_, because all the changes could be explained by just picking B and D). See? No renames. The renames is not what is fundamental here. What is fundamental is the _STATE_ of the tree. Remember: that's what git tracks, and that is what "git log" shows you. So when you do git log -- gitweb.cgi you're really asking for: "Please explain the state of the current tree with regards to gitweb.cgi that doesn't exist at this point in time". And that's _exactly_ what "git log" will do. It will say "hey, I can explain it by the file not existing in one of the previous parents either: maybe it got removed there", and walk back as far as it possibly can to explain that the file doesn't exist. And it turns out that it can walk all the way back to the root, and the file didn't exist there, so the end result is what? The empty set. Linus - : 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