Re: breakage in revision traversal with pathspec

[Jonathan Nieder <jrnieder@gmail.com>]

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 <junkio@cox.net>
	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 <junkio@cox.net>

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