From: Jeff King <peff@peff.net>
To: Taylor Blau <me@ttaylorr.com>
Cc: Junio C Hamano <gitster@pobox.com>,
Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, vdye@github.com,
Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH 0/8] ahead-behind: new builtin for counting multiple commit ranges
Date: Thu, 9 Mar 2023 04:20:53 -0500 [thread overview]
Message-ID: <ZAmk9V54c/jIbJ65@coredump.intra.peff.net> (raw)
In-Reply-To: <ZAaHB7XTz8HX75LD@nand.local>
On Mon, Mar 06, 2023 at 07:36:23PM -0500, Taylor Blau wrote:
> > This makes readers wonder if "git rev-list --count B...C" should be
> > the end-user facing UI for this new feature, perhaps?
> >
> > Of course if you are checking how C0, C1, C2,... relate to a single
> > B, the existing rev-list syntax would not work, and makes a totally
> > new subcommand a possibilty.
>
> Yeah. You could imagine that `rev-list --count` might do something
> fancy like coalescing
>
> git rev-list --count B...C1 B...C2 B...C3
>
> into a single walk. But I am not sure that just because `rev-list
> --count` provides similar functionality that we should fold in the
> proposed `ahead-behind` interface into that flag.
It does coalesce all of that into a single walk. The problem is somewhat
the opposite: it only has a notion of two "sides" for a symmetric
traversal: left and right. But in your example there are many sides, and
we have to remember which is which.
I think getting the answer from one walk would require an arbitrary
number of bits to paint down each path. Certainly the ahead-behind that
Vicent and I wrote long ago didn't do that (IIRC it mostly relied on
doing multiple traversals in the same process, which amortized the cost
of commit parsing; that's not really an issue these days with commit
graphs).
Peeking at patch 7 of Stolee's series...yep. That's exactly what it
does. :)
I wondered how much it would matter on top of a naive loop of
single-traversals, now that we have commit graphs. It looks like there's
still quite a nice speedup from the numbers in patch 7 (though the
totally naive "loop of rev-list" is incurring extra startup overhead,
too).
> My personal feeling is that we ought to avoid (further) overloading
> `rev-list` absent of a compelling reason to do so. But I am definitely
> open to other thoughts here.
So I think this actually is what "git rev-list --left-right --count
old...new" does now. But extending it to multiple sets in one traversal
means you need:
- being able to ask for individual left-right markers for each pair,
not treating all lefts and all rights together
- don't stop traversing when you hit an UNINTERESTING commit if there
are still bits to paint. In a single-pair traversal, those two are
the same thing (we stop at the merge base), but with multiple pairs
you may have to keep walking past a commit that is excluded from one
pair, but not another. This _might_ be doable if you assume all of
the left-hand bases are the same, but I didn't think hard enough to
feel confident in that. But even so, that only solves cases like
"how do these branches compare to HEAD" (which I think is what
GitHub does). But it doesn't allow "how do these branches compare to
to their respective @{upstream} refs".
So I don't think it would be impossible to make this a mode of rev-list.
And that mode might even provide flexibility for other similar
operations, like a mass "git rev-list --cherry-mark"[1]. But it is a
pretty big departure from the current rev-list traversal (to my mind,
especially the "keep walking past UNINTERESTING part). I don't mind it
as its own command.
-Peff
[1] The reason you might want a mass cherry-mark is basically doing
something like the "branches" page, but in a workflow where upstream
applies patches, like git.git. There you may want to ask about
"origin/next...$branch" for all of your branches to see which ones
have been merged where.
next prev parent reply other threads:[~2023-03-09 9:21 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-06 14:06 [PATCH 0/8] ahead-behind: new builtin for counting multiple commit ranges Derrick Stolee via GitGitGadget
2023-03-06 14:06 ` [PATCH 1/8] ahead-behind: create empty builtin Derrick Stolee via GitGitGadget
2023-03-06 18:48 ` Junio C Hamano
2023-03-07 0:40 ` Taylor Blau
2023-03-08 22:14 ` Derrick Stolee
2023-03-08 22:56 ` Junio C Hamano
2023-03-06 14:06 ` [PATCH 2/8] ahead-behind: parse tip references Derrick Stolee via GitGitGadget
2023-03-07 0:43 ` Taylor Blau
2023-03-06 14:06 ` [PATCH 3/8] ahead-behind: implement --ignore-missing option Derrick Stolee via GitGitGadget
2023-03-07 0:46 ` Taylor Blau
2023-03-06 14:06 ` [PATCH 4/8] commit-graph: combine generation computations Derrick Stolee via GitGitGadget
2023-03-06 14:06 ` [PATCH 5/8] commit-graph: return generation from memory Derrick Stolee via GitGitGadget
2023-03-06 14:06 ` [PATCH 6/8] commit-graph: introduce `ensure_generations_valid()` Taylor Blau via GitGitGadget
2023-03-06 18:52 ` Junio C Hamano
2023-03-07 0:50 ` Taylor Blau
2023-03-06 14:06 ` [PATCH 7/8] ahead-behind: implement ahead_behind() logic Derrick Stolee via GitGitGadget
2023-03-07 1:05 ` Taylor Blau
2023-03-09 17:32 ` Derrick Stolee
2023-03-06 14:06 ` [PATCH 8/8] ahead-behind: add --contains mode Derrick Stolee via GitGitGadget
2023-03-06 18:26 ` [PATCH 0/8] ahead-behind: new builtin for counting multiple commit ranges Junio C Hamano
2023-03-06 20:18 ` Derrick Stolee
2023-03-06 22:24 ` Junio C Hamano
2023-03-07 0:36 ` Taylor Blau
2023-03-09 9:20 ` Jeff King [this message]
2023-03-09 21:51 ` Junio C Hamano
2023-03-07 0:33 ` Taylor Blau
2023-03-10 17:20 ` [PATCH v2 0/8] ref-filter: ahead/behind counting, faster --merged option Derrick Stolee via GitGitGadget
2023-03-10 17:20 ` [PATCH v2 1/8] for-each-ref: add --stdin option Derrick Stolee via GitGitGadget
2023-03-10 18:08 ` Junio C Hamano
2023-03-13 10:31 ` Phillip Wood
2023-03-13 13:33 ` Derrick Stolee
2023-03-13 21:10 ` Taylor Blau
2023-03-15 13:37 ` Ævar Arnfjörð Bjarmason
2023-03-15 17:17 ` Jeff King
2023-03-15 17:49 ` Jeff King
2023-03-15 19:24 ` Junio C Hamano
2023-03-15 19:44 ` Jeff King
2023-03-10 17:20 ` [PATCH v2 2/8] for-each-ref: explicitly test no matches Derrick Stolee via GitGitGadget
2023-03-10 17:20 ` [PATCH v2 3/8] commit-graph: combine generation computations Derrick Stolee via GitGitGadget
2023-03-10 17:20 ` [PATCH v2 4/8] commit-graph: return generation from memory Derrick Stolee via GitGitGadget
2023-03-10 17:21 ` [PATCH v2 5/8] commit-graph: introduce `ensure_generations_valid()` Taylor Blau via GitGitGadget
2023-03-10 17:21 ` [PATCH v2 6/8] commit-reach: implement ahead_behind() logic Derrick Stolee via GitGitGadget
2023-03-15 13:50 ` Ævar Arnfjörð Bjarmason
2023-03-15 16:03 ` Junio C Hamano
2023-03-15 16:13 ` Derrick Stolee
2023-03-10 17:21 ` [PATCH v2 7/8] for-each-ref: add ahead-behind format atom Derrick Stolee via GitGitGadget
2023-03-10 19:09 ` Junio C Hamano
2023-03-15 13:57 ` Ævar Arnfjörð Bjarmason
2023-03-15 16:01 ` Junio C Hamano
2023-03-15 16:12 ` Derrick Stolee
2023-03-15 16:11 ` Derrick Stolee
2023-03-10 17:21 ` [PATCH v2 8/8] commit-reach: add tips_reachable_from_bases() Derrick Stolee via GitGitGadget
2023-03-15 14:13 ` Ævar Arnfjörð Bjarmason
2023-03-15 16:17 ` Derrick Stolee
2023-03-15 16:18 ` Derrick Stolee
2023-03-10 19:16 ` [PATCH v2 0/8] ref-filter: ahead/behind counting, faster --merged option Junio C Hamano
2023-03-10 19:25 ` Derrick Stolee
2023-03-15 17:31 ` Jeff King
2023-03-15 17:44 ` Derrick Stolee
2023-03-15 19:34 ` Junio C Hamano
2023-03-15 13:22 ` Ævar Arnfjörð Bjarmason
2023-03-15 13:54 ` Derrick Stolee
2023-03-15 17:45 ` [PATCH v3 " Derrick Stolee via GitGitGadget
2023-03-15 17:45 ` [PATCH v3 1/8] for-each-ref: add --stdin option Derrick Stolee via GitGitGadget
2023-03-15 18:06 ` Jeff King
2023-03-15 19:14 ` Junio C Hamano
2023-03-15 22:41 ` Jonathan Tan
2023-03-15 17:45 ` [PATCH v3 2/8] for-each-ref: explicitly test no matches Derrick Stolee via GitGitGadget
2023-03-15 17:45 ` [PATCH v3 3/8] commit-graph: combine generation computations Derrick Stolee via GitGitGadget
2023-03-15 22:49 ` Jonathan Tan
2023-03-17 18:30 ` Derrick Stolee
2023-03-15 17:45 ` [PATCH v3 4/8] commit-graph: return generation from memory Derrick Stolee via GitGitGadget
2023-03-15 22:58 ` Jonathan Tan
2023-03-15 17:45 ` [PATCH v3 5/8] commit-graph: introduce `ensure_generations_valid()` Taylor Blau via GitGitGadget
2023-03-15 17:45 ` [PATCH v3 6/8] commit-reach: implement ahead_behind() logic Derrick Stolee via GitGitGadget
2023-03-15 23:28 ` Jonathan Tan
2023-03-17 18:44 ` Derrick Stolee
2023-03-15 17:45 ` [PATCH v3 7/8] for-each-ref: add ahead-behind format atom Derrick Stolee via GitGitGadget
2023-03-15 17:45 ` [PATCH v3 8/8] commit-reach: add tips_reachable_from_bases() Derrick Stolee via GitGitGadget
2023-03-20 11:26 ` [PATCH v4 0/9] ref-filter: ahead/behind counting, faster --merged option Derrick Stolee via GitGitGadget
2023-03-20 11:26 ` [PATCH v4 1/9] for-each-ref: add --stdin option Derrick Stolee via GitGitGadget
2023-03-20 11:26 ` [PATCH v4 2/9] for-each-ref: explicitly test no matches Derrick Stolee via GitGitGadget
2023-03-20 11:26 ` [PATCH v4 3/9] commit-graph: refactor compute_topological_levels() Derrick Stolee via GitGitGadget
2023-03-20 11:26 ` [PATCH v4 4/9] commit-graph: simplify compute_generation_numbers() Derrick Stolee via GitGitGadget
2023-03-20 11:26 ` [PATCH v4 5/9] commit-graph: return generation from memory Derrick Stolee via GitGitGadget
2023-03-20 11:26 ` [PATCH v4 6/9] commit-graph: introduce `ensure_generations_valid()` Taylor Blau via GitGitGadget
2023-03-20 11:26 ` [PATCH v4 7/9] commit-reach: implement ahead_behind() logic Derrick Stolee via GitGitGadget
2023-03-20 20:40 ` Jonathan Tan
2023-03-20 11:26 ` [PATCH v4 8/9] for-each-ref: add ahead-behind format atom Derrick Stolee via GitGitGadget
2023-03-20 11:26 ` [PATCH v4 9/9] commit-reach: add tips_reachable_from_bases() Derrick Stolee via GitGitGadget
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=ZAmk9V54c/jIbJ65@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=vdye@github.com \
/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).