From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: git format-patch on empty commit Date: Mon, 11 Jan 2016 15:53:47 -0500 Message-ID: <20160111205347.GA14535@sigill.intra.peff.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: git@vger.kernel.org To: pedro rijo X-From: git-owner@vger.kernel.org Mon Jan 11 21:53:57 2016 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aIjTP-0000nB-2L for gcvg-git-2@plane.gmane.org; Mon, 11 Jan 2016 21:53:55 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759795AbcAKUxv (ORCPT ); Mon, 11 Jan 2016 15:53:51 -0500 Received: from cloud.peff.net ([50.56.180.127]:51572 "HELO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1758970AbcAKUxu (ORCPT ); Mon, 11 Jan 2016 15:53:50 -0500 Received: (qmail 13378 invoked by uid 102); 11 Jan 2016 20:53:49 -0000 Received: from Unknown (HELO peff.net) (10.0.1.1) by cloud.peff.net (qpsmtpd/0.84) with SMTP; Mon, 11 Jan 2016 15:53:49 -0500 Received: (qmail 5168 invoked by uid 107); 11 Jan 2016 20:54:07 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) by peff.net (qpsmtpd/0.84) with SMTP; Mon, 11 Jan 2016 15:54:07 -0500 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Mon, 11 Jan 2016 15:53:47 -0500 Content-Disposition: inline In-Reply-To: Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: 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