Re: [PATCH 01/11] midx-write: initial commit

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 25, 2024 at 01:30:32PM -0700, Junio C Hamano wrote:
> Taylor Blau <me@xxxxxxxxxxxx> 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@xxxxxxxxxxxx>
> > ---
> >  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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux