Re: [PATCH 2/5] xdiff: replace mmbuffer_t with mmfile_t
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 29, 2026, 18:39 UTC
- Message-ID
- <xmqq7bk3hpfk.fsf@gitster.g>
- In-Reply-To
- <20260929065239.GB1697497@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 20 quoted lines
> Our import of xdiff has two identical buffer structures: mmfile_t and > mmbuffer_t. In upstream xdiff these were actually different, but the > import in 3443546f6e (Use a *real* built-in diff generator, 2006-03-24) > simplified mmfile_t to a simple buffer. > > In xdiff we usually use mmfile_t for input and mmbuffer_t for output, > but they are really both just a ptr/len pair. I don't think that having > different types is buying us anything in terms of type safety or > semantics, and having two makes it awkward to use the same helpers for > both. In particular, an external merge driver's output is read from a > file, but we can't easily use read_mmfile(), since we want the result in > an mmbuffer_t. > > Let's use mmfile_t for both cases and drop mmbuffer_t. The latter is > probably a more descriptive name, but we have many more uses of > mmfile_t (and helpers like read_mmfile). So let's consolidate using that > name; we can always change it to something more sensible later. > > There should be no behavior change here; this is just consolidating the > types.
Obviously good.
Show 6 quoted lines
> > Signed-off-by: Jeff King <peff@peff.net> > --- > I guess this step might be controversial, but I hope not. I think the > ship has long sailed on trying to pull "upstream" changes from xdiff > (there haven't been any, and we've hacked it up quite a bit already).
I share your prediction that we will not be "synchronizing" with the upstream.