From: Junio C Hamano <gitster@pobox.com>
To: John Keeping <john@keeping.me.uk>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] format-patch: output header for empty commits
Date: Mon, 06 Mar 2023 09:08:44 -0800 [thread overview]
Message-ID: <xmqqlek9byeb.fsf@gitster.g> (raw)
In-Reply-To: <ZAMhOehmuIov/KM8@keeping.me.uk> (John Keeping's message of "Sat, 4 Mar 2023 10:45:20 +0000")
John Keeping <john@keeping.me.uk> writes:
> On Fri, Mar 03, 2023 at 09:13:27AM -0800, Junio C Hamano wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>
>> > When formatting an empty commit, it is surprising that a totally empty
>> > file is generated. Set the flag to always print the header, matching
>> > the behaviour of git-log.
>>
>> Don't these empty files help send-email as safety against sending
>> them out? Unless existing tools depend on the current behaviour in
>> such a way, I think this is quite a sensible change.
>
> Yes, send-email fails trying to send an empty file, but to me this feels
> more like an accident than an intentional safeguard. If there were
> something intentional I'd expect format-patch to fail with --allow-empty
> as an option to bypass that safety check.
>
> Since there are checks in place to avoid unintentionally creating empty
> commits,...
Speaking as the original implementer of format-patch, the original
intention was to forbid such a message to be sent out. But it was
designed back in the days when an empty commit were not used as "a
marker in the history" as widely as these days. IOW, the original
intention does not matter all that much when we have to determine if
the code with the proposed change would negatively affect _today's_
users. What the users would see is that they have been protected
from sending out such a message by mistake (an empty commit may not
be something you created but you pulled from your colleages), but
with this change the protection is no longer there.
Another worry is if the receiving end is prepared to see such a
"patch".
Overall, if we were designing format-patch/send-email/am today with
today's use cases in mind without any existing users of these three
commands, I think these three would be designed to pass an empty
commit through the chain unconditionally. But we do not live in
such a world, so perhaps some sort of opting in may be appropriate.
Thanks.
next prev parent reply other threads:[~2023-03-06 17:10 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-03 16:03 [PATCH] format-patch: output header for empty commits John Keeping
2023-03-03 17:13 ` Junio C Hamano
2023-03-04 10:45 ` John Keeping
2023-03-06 17:08 ` Junio C Hamano [this message]
2023-03-08 20:33 ` John Keeping
2023-03-08 20:43 ` Junio C Hamano
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=xmqqlek9byeb.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=john@keeping.me.uk \
/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;
as well as URLs for NNTP newsgroup(s).