Re: [PATCH 2/5] xdiff: replace mmbuffer_t with mmfile_t
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 1, 2026, 15:40 UTC
- Message-ID
- <xmqqld8h77jo.fsf@gitster.g>
- In-Reply-To
- <20260930224613.GA765052@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 23 quoted lines
> On Wed, Sep 30, 2026 at 05:32:49PM +0200, Patrick Steinhardt wrote: > >> > 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. >> >> Yeah, that was my initial reaction, too. `mmbuffer_t` is indeed a better >> name as `mmfile_t` indicates that it's coming from... well, a file. And >> that's not necessarily true. >> >> I do wonder whether we should just aim for gradual improvement and use >> `mmbuffer_t` regardless or even shoot for something altogether different >> like `struct xdiff_buf` and then simply not mind the fact that we're >> being inconsistent. That would at least be an initial step into a better >> direction in my opinion, and we can then touch up things over some time. >> >> But I won't insist on any change like that, I'm okay with keeping >> `mmfile_t`. > > I'd really prefer to punt on it for now, just because the diff would be > _so_ big, and has so many extra rabbit holes (e.g., should "mmfile_t > *mf" get a new variable name?).
I am happy enough with the fact that mmfile is shorter than mmbuffer ;-)
After all xdiff is about comparing two files, and if you do not have files to compare, you create mmfile out of what you have (which may not be a file) and pass it to xdiff, pretending it were a file. You tell the API that that mmfile has contents from what path etc., so at that point, the argument that says mmbuffer_t is more generic and can represent any non-file sources does not really matter, I would have to say.