Kevin Bracey <kevin@xxxxxxxxx> 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.
OK.
> 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.
OK.
> 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.
OK.
> 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.
OK.
> 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
....Z...A===X---o---o---B
\\ /
W---Y
"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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html