public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Dominique Martinet <asmadeus@codewreck.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Jeff King" <peff@peff.net>,
	git@vger.kernel.org, "René Scharfe" <l.s.r@web.de>,
	"Julien Moutinho" <julm@sourcephile.fr>
Subject: Re: [RFC PATCH] builtin/format-patch: print a warning for skipped merge commits?
Date: Sun, 1 Feb 2026 17:38:58 +0900	[thread overview]
Message-ID: <aX8RIq0ZUSoIue8G@codewreck.org> (raw)
In-Reply-To: <xmqqy0mep0y2.fsf@gitster.g>

(It took me a while to get back to this...)

Junio C Hamano wrote on Sun, Jan 04, 2026 at 11:27:01AM +0900:
> Dominique Martinet <asmadeus@codewreck.org> writes:
> > Okay, I can see this being confusing to people not used to format-patch
> > even with a range, but I agree it'll be annoying more often than not in
> > general so I'm fine with this.
> 
> Yup, nobody stays to be newbie forever ;-).

I think I actually fell in this newbie category myself: I hadn't
realized how hard it is to specify exactly only a merge commit in normal
git usage.

In "confusing case" I was consulted about, Julien had used jj to
(involuntarily) make a merge commit that merged two parent commits like
this:
$ jj log
○  mkwklvul Julien Moutinho 1 hour ago openvpn* 0ef9a661
│  nixos/openvpn: format with nixfmt-rfc-style
@    qsusmwyp Julien Moutinho 1 hour ago 14ef78b3
├─╮  nixos/openvpn: add netns support
○ │  vltlsmty Julien Moutinho 23 hours ago services.netns git_head() 204ac248
├─╯  nixos/netns: init module to manage network namespaces
◆  ktsspxvy Yohann Boniface 1 day ago master@NixOS 04245c47
│  (empty) arduino-cli: 1.3.1 -> 1.4.0, use finalAttrs (#469365)

So specifying `git format-patch 14ef78b3^-` wouldn't generate any
commit;
but in the normal merge case using foo^- will grab commits that are in
the second parent that aren't in the first, so to get only the merge
commit you'd need to write `foo^- --not foo^2` or some other more
complex expression...
At which point I'm not sure this warning has much benefit, and the real
problem would more be that jj let him create such an useless merge
commit with non-trivial content..


If it was just very rarely useful I might still be tempted to send the
patch, but it also breaks patch counting with e.g. `git format-patch -3`
(test t4014-format-patch.sh "format-patch doesn't consider merge
commits"):
the -3 is done by common revision `.max_count` limit, so dropping
`rev.max_parents = 1` makes format-patch skip through merge commits
without re-adding further commits, and I'm not convinced this is all
worth it.

So, thank you for the quick replies (over new year festivities no
less!), but let's leave it at this unless something compelling comes
up...


Thanks,
-- 
Dominique Martinet | Asmadeus

  reply	other threads:[~2026-02-01  8:39 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-31  3:42 [RFC PATCH] builtin/format-patch: print a warning for skipped merge commits? Dominique Martinet
2025-12-31  5:12 ` Junio C Hamano
2026-01-03 12:24   ` Dominique Martinet
2026-01-04  2:27     ` Junio C Hamano
2026-02-01  8:38       ` Dominique Martinet [this message]
2026-01-02  7:33 ` Jeff King

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=aX8RIq0ZUSoIue8G@codewreck.org \
    --to=asmadeus@codewreck.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=julm@sourcephile.fr \
    --cc=l.s.r@web.de \
    --cc=peff@peff.net \
    /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