git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: pedro rijo <pedrorijo91@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: git format-patch on empty commit
Date: Mon, 11 Jan 2016 15:53:47 -0500	[thread overview]
Message-ID: <20160111205347.GA14535@sigill.intra.peff.net> (raw)
In-Reply-To: <CAPMsMoDOqWD+a1pj6BO-QgnknJu+JwnZgefJ=MyP8rEwZQGiPQ@mail.gmail.com>

On Mon, Jan 11, 2016 at 02:19:52PM +0000, pedro rijo wrote:

> Couldn't find any explanation on git docs on this issue:
> 
> If I create a dummy commit, with some dummy diff, I get a normal patch
> when I run
> 
> $ git format-patch -1 -o outgoing/ -p -k
> 
> but if the last commit is an empty commit, generated by
> 
> $ git commit --allow-empty "Some commit message"
> 
> then the output of the format patch will be an empty patch. If the
> first case produces something like this:

I'm not sure if this is a bug or not.

In the beginning, git's revision-traversal machinery generally does not
show commits which have no diff. Over the years, commands like "git log"
learned to set the "always_show_header" option to show even empty
commits. But format-patch never did.

It's pretty easy to do:

diff --git a/builtin/log.c b/builtin/log.c
index e00cea7..f132ce7 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1283,6 +1283,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
 	rev.commit_format = CMIT_FMT_EMAIL;
 	rev.verbose_header = 1;
 	rev.diff = 1;
+	rev.always_show_header = 1;
 	rev.max_parents = 1;
 	DIFF_OPT_SET(&rev.diffopt, RECURSIVE);
 	rev.subject_prefix = fmt_patch_subject_prefix;

So on the one hand, it is probably better not to silently omit commits,
and it would make format-patch consistent with log and other commands.
And what is produced now is somewhat nonsensical. For "format-patch
--stdout", omitting the header is OK; we just skip the commit entirely.
But for writing patches to individual files, you end up with an empty
file!

On the other hand, the point of format-patch is generally to feed the
output to "git am". And I don't think "am" handles such empty patches
very well (it complains with "Patch is empty. Was it split wrong?", and
there's no way to say "no, really, just apply the empty commit").

So even if you generated such patches, I'm not sure what you would do
with them.

I'd be more sympathetic to a patch like the one above if "am" also
learned about empty commits (even if it required the user to say "empty
commits are OK, as we already do for "commit" and some other commands).
Note that the patch above also seems to trigger a test failure in t3421
(which is a rebase test, and rebase builds on "format-patch | am"). That
would need to be investigated, too. I'm not sure if there's a subtle
case I'm missing, or if the test script is simply a little too strict.

-Peff

  reply	other threads:[~2016-01-11 20:53 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-11 14:19 git format-patch on empty commit pedro rijo
2016-01-11 20:53 ` Jeff King [this message]
2016-01-11 21:04   ` Junio C Hamano
2016-01-11 21:09     ` Jeff King
2016-01-11 23:47     ` pedro rijo

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=20160111205347.GA14535@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=pedrorijo91@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;
as well as URLs for NNTP newsgroup(s).