git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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.

Previous: Jeff KingNext: Jeff King
Message 9 of 37 in “use size_t for xdiff mmfile_t”
  1. 0/5 use size_t for xdiff mmfile_tJeff King, Sep 29, 2026
  2. 1/5 xdiff: clean up read_mmfile() allocations on errorJeff King, Sep 29, 2026
  3. Junio C HamanoSep 29, 2026
  4. 2/5 xdiff: replace mmbuffer_t with mmfile_tJeff King, Sep 29, 2026
  5. D. Ben KnobleSep 29, 2026
  6. Junio C HamanoSep 29, 2026
  7. Patrick SteinhardtSep 30, 2026
  8. Jeff KingSep 30, 2026
  9. Junio C HamanoOct 1, 2026
  10. 3/5 xdiff: use size_t for buffer sizesJeff King, Sep 29, 2026
  11. 4/5 merge-ll: use read_mmfile() to read external merge resultsJeff King, Sep 29, 2026
  12. Junio C HamanoSep 29, 2026
  13. Jeff KingSep 29, 2026
  14. Jeff KingSep 29, 2026
  15. 6/5 merge-ll: handle external driver status before reading resultJeff King, Sep 29, 2026
  16. 7/5 merge-ll: report an error when reading external merge results failsJeff King, Sep 29, 2026
  17. Junio C HamanoSep 29, 2026
  18. Jeff KingSep 29, 2026
  19. Junio C HamanoSep 30, 2026
  20. Jeff KingSep 30, 2026
  21. Junio C HamanoOct 1, 2026
  22. Patrick SteinhardtSep 30, 2026
  23. Jeff KingSep 30, 2026
  24. 5/5 xdiff: NUL-terminate buffers read by read_mmfile()Jeff King, Sep 29, 2026
  25. Patrick SteinhardtSep 30, 2026
  26. Junio C HamanoSep 30, 2026
  27. Jeff KingSep 30, 2026
  28. 0/7 use size_t for xdiff mmfile_tJeff King, Sep 30, 2026
  29. 1/7 xdiff: clean up read_mmfile() allocations on errorJeff King, Sep 30, 2026
  30. 2/7 xdiff: replace mmbuffer_t with mmfile_tJeff King, Sep 30, 2026
  31. 3/7 xdiff: use size_t for buffer sizesJeff King, Sep 30, 2026
  32. 4/7 xdiff: NUL-terminate buffers read by read_mmfile()Jeff King, Sep 30, 2026
  33. Patrick SteinhardtOct 1, 2026
  34. 5/7 merge-ll: use read_mmfile() to read external merge resultsJeff King, Sep 30, 2026
  35. Patrick SteinhardtOct 1, 2026
  36. 6/7 merge-ll: handle external driver status before reading resultJeff King, Sep 30, 2026
  37. 7/7 merge-ll: report an error when reading external merge results failsJeff King, Sep 30, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.