Git development
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: "Michal Koutný" <mkoutny@suse.com>
Cc: git@vger.kernel.org, "Jean Delvare" <jdelvare@suse.de>,
	"Elijah Newren" <newren@gmail.com>,
	"Usman Akinyemi" <usmanakinyemi202@gmail.com>,
	"Taylor Blau" <me@ttaylorr.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"René Scharfe" <l.s.r@web.de>
Subject: [PATCH v2 0/3] merge-ll: Cleanup merge driver temporaries after
Date: Fri, 11 Sep 2026 13:10:44 -0400	[thread overview]
Message-ID: <20260911171044.GA1609692@coredump.intra.peff.net> (raw)
In-Reply-To: <aqQN_Q6ZAeyTy7WA@localhost.localdomain>

On Fri, Sep 11, 2026 at 04:43:08PM +0200, Michal Koutný wrote:

> > In the worst case we can just call register_tempfile() on each path, but
> > I think this code could be taught to use the actual creation. Something
> > like the patch below (only lightly tested).
> 
> I've tested it and it works (cleans up both after SIGINT and regular
> termination).

Thanks for testing. I considered putting something in the test suite,
but it gets ugly (we'd have the external driver pause, signal a fifo,
then kill git-merge and it with SIGINT). I guess an alternative would be
setting GIT_ALLOC_LIMIT to something low, and then generating a
too-large output, which would cause xmalloc() to fail, which I believe
would also fail. But then we're not really testing the signal handling.

Hmm. I wonder if leaving the files could actually be a _feature_. If you
completed the merge with the external tool but we barfed reading it back
in, would it be useful to leave the file in place? It's possible, I
suppose, but I think it is more likely to be a nuisance (and we already
delete it for things like read() errors, just not anything that would
cause us to die()).

> (There's only a warning about constness, one should not change the
> tempfile's path buffer. But here the ovewrite happens only if there were
> trialing dirseps, which they aren't as the filename is under control.)

Yeah, I've fixed it in this iteration, plus a few tweaks:

 - I did the strbuf cleanup I mentioned (patch 1)

 - we should be using close_tempfile_gently() instead of close() on the
   tempfiles so that they don't get double-closed when deleting

 - that made me notice a small error-checking bug in the original code,
   fixed in patch 2

> Do you want me to send your variant as v2 or will you?

Here it is. I've labeled it v2, and I stole your commit message for the
third patch.

  [1/3]: merge-ll: use strbuf to read back external merge result
  [2/3]: merge-ll: catch close() errors when writing external tempfiles
  [3/3]: merge-ll: use tempfile API for external driver files

 merge-ll.c | 68 +++++++++++++++++++++++++++++-------------------------
 1 file changed, 37 insertions(+), 31 deletions(-)

-Peff

  reply	other threads:[~2026-09-11 17:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 15:06 [PATCH] merge-ll: Cleanup merge driver temporaries after interrupt Michal Koutný
2026-09-10 16:22 ` Jeff King
2026-09-11 14:43   ` Michal Koutný
2026-09-11 17:10     ` Jeff King [this message]
2026-09-11 17:11       ` [PATCH v2 1/3] merge-ll: use strbuf to read back external merge result Jeff King
2026-09-11 18:06         ` Elijah Newren
2026-09-11 18:32           ` Junio C Hamano
2026-09-11 17:11       ` [PATCH v2 2/3] merge-ll: catch close() errors when writing external tempfiles Jeff King
2026-09-11 18:06         ` Elijah Newren
2026-09-11 17:13       ` [PATCH v2 3/3] merge-ll: use tempfile API for external driver files Jeff King
2026-09-11 18:10         ` Elijah Newren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260911171044.GA1609692@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jdelvare@suse.de \
    --cc=l.s.r@web.de \
    --cc=me@ttaylorr.com \
    --cc=mkoutny@suse.com \
    --cc=newren@gmail.com \
    --cc=usmanakinyemi202@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox