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 <>
        Date:   Fri Mar 10 21:59:37 2006 -0800

            try_to_simplify_commit(): do not skip inspecting tree change at 
            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:
            Signed-off-by: Junio C Hamano <>

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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to