Re: [PATCH 2/5] xdiff: replace mmbuffer_t with mmfile_t

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> 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.