From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Thomas Rast <trast@inf.ethz.ch>,
Thomas Rast <trast@student.ethz.ch>,
git@vger.kernel.org
Subject: Re: [PATCH] commit: allow {--amend|-c foo} when {HEAD|foo} has empty message
Date: Tue, 28 Feb 2012 14:59:32 -0500 [thread overview]
Message-ID: <20120228195931.GE11260@sigill.intra.peff.net> (raw)
In-Reply-To: <7vr4xe27sq.fsf@alter.siamese.dyndns.org>
On Tue, Feb 28, 2012 at 09:21:09AM -0800, Junio C Hamano wrote:
> Thomas Rast <trast@inf.ethz.ch> writes:
>
> > So either there's a lot to be fixed, or fsck needs to catch this.
>
> Your experiment with hash-object aside (that is like saying "I can write
> garbage with a disk editor, and now OS cannot read from that directory"),
Yes, but the difference between "OS cannot read from that directory" and
"OS segfaults" might be worth noticing. :)
> if somebody manages to create a commit without any body, it is clear that
> the user wanted to record no body. I think all code that tries to run
> strstr("\n\n") and increment the resulting pointer by two to find the
> beginning of the body should behave as if it found one and the result
> pointed at a NUL. Rejecting with fsck does not help anybody, as it
> happens after the fact.
Yeah, I agree that treating it like an empty body is reasonable
(possibly with a warning). But given that nobody has actually seen this
in the wild, maybe it is simpler to mark it with fsck, and to just die()
when we see it. That would hopefully alert the author of the broken tool
early, before the tools is made public. If it turns out that such
commits do end up in the wild, then we can relax the behavior then.
-Peff
next prev parent reply other threads:[~2012-02-28 19:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 8:57 [PATCH] commit: allow {--amend|-c foo} when {HEAD|foo} has empty message Thomas Rast
2012-02-28 9:05 ` Jeff King
2012-02-28 9:14 ` Jeff King
2012-02-28 9:20 ` Thomas Rast
2012-02-28 17:21 ` Junio C Hamano
2012-02-28 19:59 ` Jeff King [this message]
2012-02-28 21:12 ` Junio C Hamano
2012-02-28 10:36 ` [PATCH v2] " Thomas Rast
2012-02-28 10:37 ` [RFC PATCH 2a] pretty: detect missing \n\n in commit message Thomas Rast
2012-02-28 12:56 ` Nguyen Thai Ngoc Duy
2012-02-28 17:27 ` Junio C Hamano
2012-02-28 10:37 ` [RFC PATCH 2b] parse_commit: refuse to load commit without \n\n separator Thomas Rast
2012-02-28 17:25 ` [PATCH v2] commit: allow {--amend|-c foo} when {HEAD|foo} has empty message 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=20120228195931.GE11260@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=trast@inf.ethz.ch \
--cc=trast@student.ethz.ch \
/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).