mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Jonathan Nieder <>
Cc: Lukas Gross <>,
Subject: Re: amend warnings with no changes staged
Date: Tue, 6 Aug 2019 00:19:11 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Aug 05, 2019 at 07:16:18PM -0700, Jonathan Nieder wrote:

> Lukas Gross wrote:
> > I had intended to stage commits but forgot to do so. Git responded
> > with a normal commit creation message, so I pushed to the remote to
> > begin a CI build. When the build failed for the same reason, I
> > realized I had forgotten to stage the changes. An additional line in
> > the response to the effect of “Warning: did you mean to amend with no
> > changes?” would be very helpful to shorten this feedback loop.
> On second thought:
> 	$ git commit --amend --no-edit
> 	[detached HEAD 33a3db8805] Git 2.23-rc1
> 	 Author: Junio C Hamano <>
> 	 Date: Fri Aug 2 13:12:24 2019 -0700
> 	 2 files changed, 2 insertions(+), 1 deletion(-)
> 	$
> Some non-judgemental descriptive output like
> 	$ git commit --amend --no-edit
> 	No changes.
> 	$
> would address this case, without bothering people who are doing it
> intentionally.  So I think there's room for a simple improvement here.
> Care to take a stab at it?  builtin/commit.c would be the place to
> start.

I'm not clear on the situation from your second change. There are two
sets of changes to talk about here: the changes between the new commit
and its parent, and the changes between the original commit and the
amended version.

The output in your first example is showing the differences to the
parent. Do you mean in the second example that there are no changes to
the parent, and thus we say "No changes"? If not, then what happened to
that output? :)

And if so, then I don't think it is solving Lukas's problem. I imagine
the issue to be (because I have done this myself many times):

  git commit -m 'buggy commit'
  echo fix >>file.c
  git commit --amend ;# oops, should have been "-a"
  git push

But perhaps that gets to the heart of the matter. Could we perhaps be
providing a more detailed summary of what happened for an --amend? I.e.,
to summarize _both_ sets of changes (and if one set is empty, say so)?

I'm not quite sure how to make that readable. Something like:

  $ git commit --amend
  [master 5787bce] some commit subject
   Date: Tue Aug 6 00:03:28 2019 -0400
  Changes introduced by this commit (diff HEAD^):
   1 file changed, 1 insertion(+)
   create mode 100644 added-by-broken-commit
  Changes from the amend commit (diff HEAD@{1}):
   1 file changed, 1 insertion(+)
   create mode 100644 added-during-amend

is pretty ugly. And anyway, because it's just the diffstat total, it's
hard to see whether it contains your changes or not (i.e., would you
notice if you forgot to stage 3 lines from some random file). OTOH, if
the common case we care about is just "you didn't stage anything as part
of the amend", then it would be enough to let you know (without making a
judgement about whether it's an error, since it may well be that you
were simply rewording the commit message).


  parent reply	other threads:[~2019-08-06  4:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-06  0:28 amend warnings with no changes staged Lukas Gross
2019-08-06  1:30 ` Jonathan Nieder
2019-08-06  1:37   ` Lukas Gross
2019-08-06  2:01     ` Jonathan Nieder
2019-08-06  2:16     ` Jonathan Nieder
2019-08-06  2:47       ` Junio C Hamano
2019-08-06  3:00         ` Jonathan Nieder
2019-08-06  3:29           ` Junio C Hamano
2019-08-06  3:53             ` Junio C Hamano
2019-08-06 16:32               ` Phillip Wood
2019-08-06  4:19       ` Jeff King [this message]
2019-08-06 19:11         ` Junio C Hamano
2019-08-08  9:46           ` 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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

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 read-only IMAP folder(s) and NNTP newsgroup(s).