On 10/09/2013 20:19, Junio C Hamano wrote:
I am grumpy X-<.

It appears that we introduced a large breakage during 1.8.4 cycle to
the revision traversal machinery and made pathspec-limited "git log"
pretty much useless.

This command

     $ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl

reports that a merge 766f0f8ef7 (which did not touch the specified
path at all) touches it.

Bisecting points at d0af663e (revision.c: Make --full-history
consider more merges, 2013-05-16).

That merge appearing *with* --full-history would seem like correct behaviour to me. Or at least it's what I intended.

That merge *did* touch that path - that file differs between the two parents, and it resolved on one of them.

This goes back to my original motivation for the change - the ability to find merges that resolved in unexpected ways - I want "--full-history" to show every merge where the end result is not identical to every parent.

This does mean that "--full-history" will show more merges than it used to for a pathspec - it will show merges in from topic branches which didn't touch that pathspec, but where the mainline did change it.

These extra merges can be pared back by "--simplify-merges", which will generally eliminate any irrelevant topic branches, although not for topic branches that are rooted older than your bottom commit, like in this example.

However, your particular example occurs *without*--full-history, which suggests a problem.

That merge is right near the bottom of the range. Its first parent is v1.8.3. It has an incoming pre-1.8.3 topic branch (fc/transport-helper-error-reporting) with an old version of git-cvsserver.perl (which the merge correctly didn't take). Display of that sort of bottom-of-range merge is a problem area I did try to address - it was problematic in older Git versions, but that problem was partially concealed by the overly-permissive "hide any merge identical to any one parent" logic, and became more exposed by my "show more merges".

I'm pretty certain non-full "git log v1.8.3..v1.8.4" shouldn't show that merge. And indeed it doesn't. Yay! At this point the various "follow first parent if identical", "prioritise on-graph treesame" and "treat bottom commits as on-graph" rules are working. That merge is identical to v1.8.3, its first parent, and we've expressed an interest in v1.8.3, so that's treated as on-graph, so it doesn't get shown.

(Oddly, "gitk v1.8.3..v1.8.4" fails and shows the merge. It seems gitk fails here because of the annotated tag: "gitk v1.8.3^0..v1.8.4" correctly shows nothing. So one apparent "failure to peel" bug somewhere. Can't seem to provoke this with git log.)

"git log v1.8.3.1..v1.8.4" on the other hand I'm not so sure about. The "follow first treesame parent" logic doesn't kick in because the merge's only treesame parent (v1.8.3) is off-graph. The merge is not treesame to its only on-graph parent (fc/transport-helper-error-reporting), so that "default following" rule doesn't activate.

I'm going to have to think a bit. "git log (--ancestry-path?) fc/transport-helper-error-reporting..v1.8.4" should definitely show that merge - we want to see how we got from the version of the file on the specified topic branch to the different version in v1.8.4.

Maybe if the first-treesame-parent rule was reapplied again later after rewriting? After we've pruned away the topic branch by rewriting because its commits don't touch the pathspec, then our merge is left with two off-graph rewritten parents. At which point maybe it would be reasonable for the default log to reapply the "follow first treesame parent" rule if all remaining parents are off-graph.

Does that make sense? Going to have to think harder.

I note that "gitk v1.8.3^0..v1.8.4" and "git log --parents v1.8.3..v1.8.4" show that merge in Git 1.8.3, but not in Git 1.8.4. So we're going partially forwards, at least.


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to