From: Taylor Blau <me@ttaylorr.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH 01/11] midx-write: initial commit
Date: Mon, 25 Mar 2024 18:09:40 -0400 [thread overview]
Message-ID: <ZgH2JJZ1sdVeVne2@nand.local> (raw)
In-Reply-To: <xmqq1q7yjbpz.fsf@gitster.g>
On Mon, Mar 25, 2024 at 01:30:32PM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr.com> writes:
>
> > Introduce a new empty midx-write.c source file. Similar to the
> > relationship between "pack-bitmap.c" and "pack-bitmap-write.c", this
> > source file will hold code that is specific to writing MIDX files as
> > opposed to reading them (the latter will remain in midx.c).
> >
> > This is a preparatory step which will reduce the overall size of midx.c
> > and make it easier to read as we prepare for future changes to that file
> > (outside the immediate scope of this series).
> >
> > Signed-off-by: Taylor Blau <me@ttaylorr.com>
> > ---
> > Makefile | 1 +
> > midx-write.c | 2 ++
> > 2 files changed, 3 insertions(+)
> > create mode 100644 midx-write.c
> >
> > diff --git a/Makefile b/Makefile
> > index 4e255c81f2..cf44a964c0 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1072,6 +1072,7 @@ LIB_OBJS += merge-ort-wrappers.o
> > LIB_OBJS += merge-recursive.o
> > LIB_OBJS += merge.o
> > LIB_OBJS += midx.o
> > +LIB_OBJS += midx-write.o
> > LIB_OBJS += name-hash.o
> > LIB_OBJS += negotiator/default.o
> > LIB_OBJS += negotiator/noop.o
> > diff --git a/midx-write.c b/midx-write.c
> > new file mode 100644
> > index 0000000000..214179d308
> > --- /dev/null
> > +++ b/midx-write.c
> > @@ -0,0 +1,2 @@
> > +#include "git-compat-util.h"
> > +#include "midx.h"
>
> I noticed that "nm midx-write.o" after this step gives us nothing.
> A source that produces absolutely nothing may not successfully
> compile everywhere. It is unlikely we will stop the series at this
> step and it won't break bisection, though.
>
> I do not quite see why the first 3 patches need to be split this
> way, rather than being done as a single step. Is it making the
> review any simpler?
I was hoping that it would make review simpler. If you're concerned
about an empty compilation unit, we could:
- combine the first three patches into one, so that we start by just
porting `midx_repack()`
- combine the first seven patches into one, so that the move is done in
a single step, or
- leave it as-is
Whatever you think makes most sense is fine with me. The original
motivation behind splitting them was to make the steps easier to review,
but if that doesn't seem to be the case, I'm happy to combine them.
Thanks,
Taylor
next prev parent reply other threads:[~2024-03-25 22:09 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-25 17:24 [PATCH 00/11] midx: split MIDX writing routines into midx-write.c, cleanup Taylor Blau
2024-03-25 17:24 ` [PATCH 01/11] midx-write: initial commit Taylor Blau
2024-03-25 20:30 ` Junio C Hamano
2024-03-25 22:09 ` Taylor Blau [this message]
2024-03-25 17:24 ` [PATCH 02/11] midx: extern a pair of shared functions Taylor Blau
2024-03-25 17:24 ` [PATCH 03/11] midx: move `midx_repack` (and related functions) to midx-write.c Taylor Blau
2024-03-25 17:24 ` [PATCH 04/11] midx: move `expire_midx_packs` " Taylor Blau
2024-03-25 17:24 ` [PATCH 05/11] midx: move `write_midx_file_only` " Taylor Blau
2024-03-25 17:24 ` [PATCH 06/11] midx: move `write_midx_file` " Taylor Blau
2024-03-25 17:24 ` [PATCH 07/11] midx: move `write_midx_internal` (and related functions) " Taylor Blau
2024-03-25 17:24 ` [PATCH 08/11] midx-write.c: avoid directly managed temporary strbuf Taylor Blau
2024-03-25 20:33 ` Junio C Hamano
2024-03-25 22:11 ` Taylor Blau
2024-03-25 17:24 ` [PATCH 09/11] midx-write.c: factor out common want_included_pack() routine Taylor Blau
2024-03-25 20:36 ` Junio C Hamano
2024-03-27 8:29 ` Jeff King
2024-03-25 17:24 ` [PATCH 10/11] midx-write.c: check count of packs to repack after grouping Taylor Blau
2024-03-25 20:41 ` Junio C Hamano
2024-03-25 22:11 ` Taylor Blau
2024-03-25 17:24 ` [PATCH 11/11] midx-write.c: use `--stdin-packs` when repacking Taylor Blau
2024-03-27 8:37 ` Jeff King
2024-03-27 8:39 ` [PATCH 00/11] midx: split MIDX writing routines into midx-write.c, cleanup Jeff King
2024-04-01 21:16 ` [PATCH v2 0/4] " Taylor Blau
2024-04-01 21:16 ` [PATCH v2 1/4] midx-write: move writing-related functions from midx.c Taylor Blau
2024-04-01 21:16 ` [PATCH v2 2/4] midx-write.c: factor out common want_included_pack() routine Taylor Blau
2024-04-02 11:47 ` Patrick Steinhardt
2024-04-01 21:16 ` [PATCH v2 3/4] midx-write.c: check count of packs to repack after grouping Taylor Blau
2024-04-01 21:16 ` [PATCH v2 4/4] midx-write.c: use `--stdin-packs` when repacking Taylor Blau
2024-04-01 21:45 ` Junio C Hamano
2024-04-02 11:47 ` 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=ZgH2JJZ1sdVeVne2@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--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.
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).