From: Junio C Hamano <gitster@pobox.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Jeff King <peff@peff.net>,
git@vger.kernel.org
Subject: Re: [RFH] revision limiting sometimes ignored
Date: Tue, 05 Feb 2008 22:05:54 -0800 [thread overview]
Message-ID: <7vhcgm4o1p.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <7v7ihi7syj.fsf@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Tue, 05 Feb 2008 17:51:32 -0800")
Junio C Hamano <gitster@pobox.com> writes:
> As Linus earlier said, the question really is: for positive
> commits in "newlist", have we not missed any its UNINTERESTING
> descendants?
>
> For a toy-scale graph, a parallel merge-base traversal like what
> show-branch does may work, but for a real workload, newlist
> would contain literally hundreds of commits, so using unaltered
> "merge-base" algorithm is probably not an option either.
After exiting the while (list) we need to prove that each
positive commit in "newlist" cannot be reached by any of the
negative commit still in "list".
Even though "newlist" may have thousands of commits, we do not
have to inspect all of them. In order to prove that we
traversed everything that matters, we will only need to look at
the ones whose ancestors are not in "newlist" (bottom commits)
and see if each of them can be reached from the negative ones.
If a non-bottom commit is reachable from one of the negative
ones, then the bottom commit that is ancestor of that non-bottom
commit surely is reachable as well.
We can make one pass to mark everything on "newlist" with one
bit from flags, and then another pass to mark the positive ones
whose parent has that bit set, so we would need two bits in
total while finding out the set of bottom commits (we can reuse
these two bits after we know what they are).
Once we find the set of bottom commits in "newlist", we would
need to prove that none of them can be reached from any of the
negative commits still in "list". We can do this traversal
using two bits from flags, exactly like commit.c::merge_bases()
for each bottom commit B {
L = empty list
B.flags |= PARENT2
L.append(B)
for each negative commit C in "list from limit_list()"
C.flags |= PARENT1
L.append(C)
while (L) {
C = shift L;
flag = C.flags & (PARENT1|PARENT2);
if (flag == (PARENT1|PARENT2))
continue; /* common */
for each parent P of commit C:
pflag = P.flags & (PARENT1|PARENT2);
if (pflag == flag)
continue;
P.flags |= flags;
L.append(P)
}
if (B.flags & PARENT1)
we still need to traverse -- everybody_uninteresting()
in limit_list() main loop was not enough!
}
next prev parent reply other threads:[~2008-02-06 6:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-02 12:21 [BUG?] git log picks up bad commit Tilman Sauerbeck
2008-02-03 3:00 ` Jeff King
2008-02-03 4:33 ` [RFH] revision limiting sometimes ignored Jeff King
2008-02-03 6:24 ` Junio C Hamano
2008-02-03 6:39 ` Junio C Hamano
2008-02-03 7:13 ` Jeff King
2008-02-03 7:18 ` Jeff King
2008-02-03 7:40 ` Junio C Hamano
2008-02-03 7:47 ` Junio C Hamano
2008-02-03 8:18 ` Junio C Hamano
2008-02-04 17:32 ` Linus Torvalds
2008-02-04 17:37 ` Linus Torvalds
2008-02-04 19:08 ` Junio C Hamano
2008-02-04 20:03 ` Linus Torvalds
2008-02-04 20:06 ` Linus Torvalds
2008-02-04 20:50 ` Linus Torvalds
2008-02-05 7:14 ` Junio C Hamano
2008-02-05 21:23 ` Linus Torvalds
2008-02-05 22:34 ` Johannes Schindelin
2008-02-05 23:59 ` Linus Torvalds
2008-02-06 16:43 ` Tilman Sauerbeck
2008-02-06 17:28 ` Nicolas Pitre
2008-02-06 17:42 ` Linus Torvalds
2008-02-06 17:48 ` Nicolas Pitre
2008-02-06 19:26 ` Linus Torvalds
2008-02-06 1:22 ` Nicolas Pitre
2008-02-06 1:51 ` Junio C Hamano
2008-02-06 6:05 ` Junio C Hamano [this message]
2008-02-06 6:17 ` Junio C Hamano
2008-02-05 23:44 ` Junio C Hamano
2008-02-06 0:52 ` Linus Torvalds
2008-02-06 5:30 ` Junio C Hamano
2008-02-06 8:16 ` Karl Hasselström
2008-02-06 10:34 ` Linus Torvalds
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vhcgm4o1p.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=torvalds@linux-foundation.org \
/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.
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 NNTP newsgroup(s).