Kevin Bracey <> writes:

> The simplification and rewriting logic previously paid little heed to
> whether parents were UNINTERESTING, leading to situations where limited
> histories could unnecessarily include a lot of irrelevant merges along
> the boundary. Tighten up the rules to properly account for limited
> lists:
> 1) If a merge has INTERESTING parents, and it is TREESAME to them, then
> do not let UNINTERESTING parents cause the merge to be treated as
> !TREESAME. If we match our walked parents, we don't care if we don't
> match unwalked parents.


> 2) Do not let UNINTERESTING parents prevent commits from being
> simplified or omitted: merges with exactly 1 INTERESTING parent that
> they are TREESAME to can be treated as a non-merge commit.


> 3) When rewriting parents, we don't need to show all merges - only merges
> with 2 or more INTERESTING parents are required to hold topology together.


> These changes greatly increase simplification in pruned, limited
> revision lists - irrelevant merges from unlisted or partially listed
> side branches can be omitted.

It is a bit unclear what "unlisted" and "partially listed" mean in
this sentence.

> These rules paying more attention to UNINTERESTING do add a tricky
> wrinkle to behaviour. Because limited revision lists are conventionally
> expressed as A..B (ie B ^A), the bottom commit is UNINTERESTING.


> Thus
> its connection to the INTERESTING graph is not privileged over side
> branches,

I take that "its connection" refers to the "===" link below, the
nodes connected with "---" form the "INTERESTING graph", and

          \\    /  
"side branches" refer to the development that built W and Y and
merged at X.  And you are saying that A===X is not "privileged" over
"Y---X", with some definition of "privileged" I am not sure about.

> and this can lead to its first descendant merge being shown
> for no particularly good reason.

Whose first descendant merge?  Sorry, I am lost at this point, and
anything I would say in the remainder of this response may be
nonsense coming from this confusion.

> See t6019's "--ancestry-path G..M -- G.t" for an example of this effect.

>  #          D---E-------F
>  #         /     \       \
> +#    B---C-G0-G--H---I---J
>  #   /                     \
>  #  A-------K---------------L--M
>  #
> +#  D..M                 == E F G G0 H I J K L M
>  #  --ancestry-path D..M == E F H I J L M
>  #
>  #  D..M -- M.t                 == M
>  #  --ancestry-path D..M -- M.t == M
>  #
>  #  G..M -- G.t                 == [nothing - was dropped in "-s ours" merge 
> L]
> -#  --ancestry-path G..M -- G.t == H J L
> +#  --ancestry-path G0..M-- G.t == G L

> Merges H and J are semantically identical and equally irrelevant, from
> the point of view of tracking the history of G.t, but H is shown and J
> isn't.
> > Bottom commit G is marked UNINTERESTING, and thus isn't
> privileged over E, so H is shown because it differs from E.

Doesn't that suggest we should do --ancestry-path a lot earlier?

Conceptually, the "ancestry-path" shouldn't get affected by any
pathspec. The range "--ancestry-path G0..M" should be equivalent to
the range "G0..M ^F ^E ^K", and with the rule to ignore non-sameness
with uninteresting side branches, I would have expected that H and J
would be equally irrelevant, because E and F would be outside the
graph we would want to look at sameness.

> Whereas
> higher up the graph, I is INTERESTING and thus privileged over F, so we
> don't care that J differs from F.
> So should we treat bottom commits as "interesting" for the rules above?

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