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 <jun...@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 <jun...@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
--
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
