Re: breakage in revision traversal with pathspec

Kevin Bracey wrote:

On reflection I'm not sure what we should for the "simple history"
view of v1.8.3.1..v1.8.4. We're not rewriting parents, so we don't
get a chance to reconsider the merge as being zero-parent, and we do
have this little section of graph to traverse at the bottom:

          1.8.3
            o----x----x----x----x---x---     (x = included, o = excluded, *=!treesame)
                /
               /*
  o--x--x--x--x

[...]

1) if identical to any on-graph parent, follow that one, and rewrite
the merge as a non-merge. We currently do not follow to an identical
off-graph parent. This long-standing comment in try_to_simplify_commit
applies: "Even if a merge with an uninteresting side branch brought
the entire change we are interested in, we do not want to lose the
other branches of this merge, so we just keep going."

[...]

2) If rule 1 doesn't activate, and it remains as a merge, hide it if
treesame to all on-graph parents. Previously this rule was "hide if
treesame to any parent", and so that would have hidden the merge.

Now, when I changed rule 2, I did not think this would affect the
default log. See my commit message:

[...]

I currently feel instinctively more disposed to dropping the older
"don't follow off-graph identical parents" rule. Let the default
history go straight to v1.8.3 even though it goes off the graph,
stopping us traversing the topic branch.

Thanks for this analysis.  Interesting.

The rule (1) comes from v1.3.0-rc1~13^2~6:

	commit f3219fbbba32b5100430c17468524b776eb869d6
	Author: Junio C Hamano [off-list ref]
	Date:   Fri Mar 10 21:59:37 2006 -0800

	    try_to_simplify_commit(): do not skip inspecting tree change at boundary.
	    
	    When git-rev-list (and git-log) collapsed ancestry chain to
	    commits that touch specified paths, we failed to inspect and
	    notice tree changes when we are about to hit uninteresting
	    parent.  This resulted in "git rev-list since.. -- file" to
	    always show the child commit after the lower bound, even if it
	    does not touch the file.  This commit fixes it.
	    
	    Thanks for Catalin for reporting this.
	    
	    See also:
		461cf59f8924f174d7a0dcc3d77f576d93ed29a4
	    
	    Signed-off-by: Junio C Hamano [off-list ref]

I think you're right that dropping the "don't follow off-graph
treesame parents" rule would be a sensible change.  The usual point of
the "follow the treesame parent" rule is to avoid drawing undue
attention to merges of ancient history where some of the parents are
side-branches with an old version of the files being tracked and did
not actually change those files.  That rationale applies just as much
for a merge on top of an UNINTERESTING rev as any other merge.

Thanks,
Jonathan