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@xxxxxxx> 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@xxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html