git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 6/8] commit: provide a fast multi-tip contains function
Date: Tue, 01 Jul 2014 12:14:08 -0700	[thread overview]
Message-ID: <xmqqoax8x56n.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqwqbxvtaa.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Tue, 01 Jul 2014 11:16:29 -0700")

Junio C Hamano <gitster@pobox.com> 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 traversal cannot terminate if
> it reaches a commit that is reachable from one Right ref---we may
> find that we can reach more Right refs by following its ancestor.
> We can stop when we paint Right bits fully, of course, but I wonder
> if we can do better than that.
>
> Suppose we just painted a commit with L and Rn bit (i.e. the commit
> is a common ancestor of the $commit and one branch).  We know that
> traversing down from there will never reach the tip of the branch
> whose color is Rn (otherwise we will have a cycle from that commit
> back to the tip of the branch), so if the reason we are continuing
> the traversal is to prove that the tip of the branch Rn is reachable
> (or unreachable) from $commit, there is no reason to continue
> digging from there.  Can we exploit that to terminate the traversal
> earlier?

I forgot to mention this case because with "branch --no-merged pu"
it never happens, but another clue we can terminate traversal earier
with is when $commit is found to be an ancestor of some Right
commits.  Then we can start ignoring Rn bits for these Right commits
that can reach the Left one, as we know they can never be reached
from the Left.  That is, the last sentence in the paragraph ...

> When we encounter a new commit that is painted with L bit and some
> but not necessarily all R bits, we propagate the bits and check the
> R bits.  Some of the commits in Right set that correspond to R bits
> may have been painted in L (i.e. we found branches that are merged
> to $commit), and digging further from this commit will not give us
> any new information.  Other commits are not painted in L (i.e. we do
> not yet know if $commit merges these branches), so we may need to
> keep digging.  So perhaps we can stop if a commit is painted in L
> and also has all the R bits that correspond to Right commits that
> are not yet proven reachable from $commit (i.e. not painted in L)?

... will be more like "ignore Rn bits for Right commits that are
painted in L (i.e. they are reachable from L) or the Left commit is
painted with (i.e. they reach L)".

  reply	other threads:[~2014-07-01 19:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-25 23:34 [PATCH 0/8] use merge-base for tag --contains Jeff King
2014-06-25 23:35 ` [PATCH 1/8] tag: allow --sort with -n Jeff King
2014-06-25 23:35 ` [PATCH 2/8] tag: factor out decision to stream tags Jeff King
2014-06-25 23:39 ` [PATCH 3/8] paint_down_to_common: use prio_queue Jeff King
2014-07-01 16:23   ` Junio C Hamano
2014-07-01 17:10     ` Jeff King
2014-06-25 23:40 ` [PATCH 4/8] add functions for memory-efficient bitmaps Jeff King
2014-06-26  3:15   ` Torsten Bögershausen
2014-06-26 15:51     ` Jeff King
2014-06-29  7:41   ` Eric Sunshine
2014-06-30 17:07     ` Jeff King
2014-07-01 16:57       ` Junio C Hamano
2014-07-01 17:18         ` Jeff King
2014-06-25 23:42 ` [PATCH 5/8] string-list: add pos to iterator callback Jeff King
2014-07-01 17:45   ` Junio C Hamano
2014-07-01 19:00     ` Jeff King
2014-06-25 23:47 ` [PATCH 6/8] commit: provide a fast multi-tip contains function Jeff King
2014-06-26 18:55   ` Junio C Hamano
2014-06-26 19:19     ` Junio C Hamano
2014-06-26 19:26       ` Junio C Hamano
2014-07-01 18:16       ` Junio C Hamano
2014-07-01 19:14         ` Junio C Hamano [this message]
2014-06-25 23:49 ` [PATCH 7/8] tag: use commit_contains Jeff King
2014-06-25 23:53 ` [PATCH 8/8] perf: add tests for tag --contains Jeff King
2014-06-26  0:01   ` Jeff King
2014-06-26  0:04     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqoax8x56n.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).