Junio C Hamano writes:
> I forgot about the other direction, i.e. "branch --merged $commit".
> Since I do "git branch --no-merged pu" fairly often, I care about
> its performance ;-)
>
> We paint $commit as Left, and tips of all the branches as Right. We
> try to paint down from $commit but the
Junio C Hamano writes:
> If you are trying to do "branch --with $commit", what you would want
> is not exactly "paint-down-to-common(all branches, $commit)", but
> something that paints down to $commit from all branches, with an
> optimization that cuts off the traversal at a commit that is
> rea
Junio C Hamano writes:
> What does it mean to look for "branch --with $commit1 $commit2"
> (i.e. more than one in the Left set)? If we are trying to see which
> branches reach _both_ of these commits, then replace the ablve with
> "if a commit is already painted as reachable from both $commit{1,
Junio C Hamano writes:
> The only time you can say "Ah, we've seen this one and no need to
> dig further" is when you are propagating a colour C and the parent
> in question is already painted in C (it is OK to be painted as
> reachable from more tips), I would think, so shouldn't the loop be
> m
Jeff King writes:
> I haven't quite convinced myself that the stale logic in the middle is
> right. The origin paint_down function checks "PARENT1 | PARENT2" to see
> if we found a merge base (even though PARENT2 may represent many tips).
> Here I check whether we have _any_ "left" parent flag an
When commands like "git branch --contains" want to know
which branches contain a particular commit, they run a
series of merge-base calculations, one per branch. This can
be very slow if you have a large number of branches.
We made "tag --contains" faster in ffc4b80 (tag: speed up
--contains calcu
6 matches
Mail list logo
