From: Taylor Blau <me@ttaylorr.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Elijah Newren <newren@gmail.com>,
Patrick Steinhardt <ps@pks.im>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH v2 0/8] midx-write: miscellaneous clean-ups for incremental MIDXs
Date: Thu, 30 May 2024 09:59:03 -0400 [thread overview]
Message-ID: <ZliGJ0EYSfj2LhyY@nand.local> (raw)
In-Reply-To: <20240530071432.GD1949834@coredump.intra.peff.net>
On Thu, May 30, 2024 at 03:14:32AM -0400, Jeff King wrote:
> On Wed, May 29, 2024 at 06:55:15PM -0400, Taylor Blau wrote:
>
> > This is a small reroll of my series which has a grab-bag of midx-write
> > related cleanups that I pulled out of a larger series to implement
> > incremental MIDX chains.
>
> These all look pretty reasonable to me. Thanks for breaking them off of
> the larger series. I think it's generally nice to get things in smaller
> chunks.
Thanks for reviewing! It is much appreciated, as always :-).
> Sometimes it is a little tough to evaluate refactorings without seeing
> the larger context in which they'd be used. But all of these were either
> immediate improvements, or didn't take much imagination to see where
> they'd make later things easier.
Yeah, I feel like this is something that I'm still trying to find the
right balance with. I think with the pseudo-merge bitmaps series, I
erred on the side of making the series too large, which made it
difficult to easily review.
Seeing the review process on that series made me a little uneasy about
sending the incremental MIDX bitmaps series, which was growing similarly
large. I think that seeing these 8 patches or so get sent in preparation
makes the later series easier to review, but I agree that they are
somewhat unsatisfying on their own.
I think in this case it was a reasonable trade-off to make, but you
could probably make a compelling case either way there ;-).
On the bright side, what was once a ~30 patch series is now three series
(of which this is the first one). The main series is now 13 or so
patches, the end state of which is to have incremental MIDXs working
without support for reachability bitmaps. The final series I'm planning
in this area adds support for reachability bitmaps with incremental
MIDXs, but that series is only half a dozen or so patches.
I'm hoping that by sending it in chunks, the end-to-end review process
will be more straightforward and approachable. If you have any other
ideas to make it easier, definitely let me know!
Thanks,
Taylor
next prev parent reply other threads:[~2024-05-30 13:59 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-23 16:37 [PATCH 0/8] midx-write: miscellaneous clean-ups for incremental MIDXs Taylor Blau
2024-05-23 16:38 ` [PATCH 1/8] midx-write.c: tolerate `--preferred-pack` without bitmaps Taylor Blau
2024-05-29 7:47 ` Patrick Steinhardt
2024-05-29 22:29 ` Taylor Blau
2024-05-23 16:38 ` [PATCH 2/8] midx-write.c: reduce argument count for `get_sorted_entries()` Taylor Blau
2024-05-29 7:47 ` Patrick Steinhardt
2024-05-29 22:35 ` Taylor Blau
2024-05-23 16:38 ` [PATCH 3/8] midx-write.c: pass `start_pack` to `get_sorted_entries()` Taylor Blau
2024-05-29 7:48 ` Patrick Steinhardt
2024-05-29 22:36 ` Taylor Blau
2024-05-23 16:38 ` [PATCH 4/8] midx-write.c: extract `should_include_pack()` Taylor Blau
2024-05-29 7:48 ` Patrick Steinhardt
2024-05-29 22:40 ` Taylor Blau
2024-05-23 16:38 ` [PATCH 5/8] midx-write.c: extract `fill_packs_from_midx()` Taylor Blau
2024-05-23 16:38 ` [PATCH 6/8] midx-write.c: support reading an existing MIDX with `packs_to_include` Taylor Blau
2024-05-29 7:48 ` Patrick Steinhardt
2024-05-29 22:46 ` Taylor Blau
2024-05-23 16:38 ` [PATCH 7/8] midx: replace `get_midx_rev_filename()` with a generic helper Taylor Blau
2024-05-23 16:38 ` [PATCH 8/8] pack-bitmap.c: reimplement `midx_bitmap_filename()` with helper Taylor Blau
2024-05-29 22:55 ` [PATCH v2 0/8] midx-write: miscellaneous clean-ups for incremental MIDXs Taylor Blau
2024-05-29 22:55 ` [PATCH v2 1/8] midx-write.c: tolerate `--preferred-pack` without bitmaps Taylor Blau
2024-05-29 22:55 ` [PATCH v2 2/8] midx-write.c: reduce argument count for `get_sorted_entries()` Taylor Blau
2024-05-29 22:55 ` [PATCH v2 3/8] midx-write.c: pass `start_pack` to `compute_sorted_entries()` Taylor Blau
2024-05-30 6:59 ` Jeff King
2024-05-29 22:55 ` [PATCH v2 4/8] midx-write.c: extract `should_include_pack()` Taylor Blau
2024-05-29 22:55 ` [PATCH v2 5/8] midx-write.c: extract `fill_packs_from_midx()` Taylor Blau
2024-05-29 22:55 ` [PATCH v2 6/8] midx-write.c: support reading an existing MIDX with `packs_to_include` Taylor Blau
2024-05-30 7:05 ` Jeff King
2024-05-29 22:55 ` [PATCH v2 7/8] midx: replace `get_midx_rev_filename()` with a generic helper Taylor Blau
2024-05-30 7:10 ` Jeff King
2024-05-29 22:55 ` [PATCH v2 8/8] pack-bitmap.c: reimplement `midx_bitmap_filename()` with helper Taylor Blau
2024-05-30 7:14 ` [PATCH v2 0/8] midx-write: miscellaneous clean-ups for incremental MIDXs Jeff King
2024-05-30 13:59 ` Taylor Blau [this message]
2024-05-31 8:28 ` Patrick Steinhardt
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=ZliGJ0EYSfj2LhyY@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
/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).