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

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