From: Junio C Hamano Date: Thu, 01 Oct 2026 15:40:59 GMT Subject: Re: [PATCH 2/5] xdiff: replace mmbuffer_t with mmfile_t Message-ID: In-Reply-To: <20260930224613.GA765052@coredump.intra.peff.net> Jeff King 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.