Re: [PATCH v2 8/8] revision.c: discount UNINTERESTING parents
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 30, 2013, 21:18 UTC
- Message-ID
- <7vmwsfbtu7.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <1367342788-7795-9-git-send-email-kevin@bracey.fi>
Kevin Bracey <kevin@bracey.fi> writes:
Show 10 quoted lines
> 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.
Show 15 quoted lines
> # 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
Show 5 quoted lines
> 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.
Show 5 quoted lines
> 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?