git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Lukas Gross <lukasgross@u.northwestern.edu>
Cc: git@vger.kernel.org
Subject: Re: amend warnings with no changes staged
Date: Mon, 5 Aug 2019 19:01:32 -0700	[thread overview]
Message-ID: <20190806020132.GB61803@google.com> (raw)
In-Reply-To: <CAOY1tUVpeUftgHNuZg-2fMD9D+Qz08hfvRvQDe1f8+MV2xYv2w@mail.gmail.com>

(administrivia: please don't top-post)
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.

Ah, I see.  You passed --no-edit so you didn't see the usual --dry-run
style output that "git commit" shows.  You forgot to run "git add"
before amending, and this is what you'd like commit to assist you
with.

That said, this is sometimes an operation people perform
intentionally.

Ideas:

* Can the documentation do a better job of steering people away
  from --no-edit?  The hints shown when "git commit --amend" (and
  --no-amend, for that matter) open a text editor tend to be very
  helpful for understanding what is going to happen.  If any
  documentation is leading people to forgo that tool, we should fix
  it.

* Should "git commit --no-edit" say a little more about what it did,
  since it knows that the user didn't get to see the text editor?

* Should we have a special option (e.g. "git commit --amend
  --refresh") for a no-op amend?  That ways, when a user doesn't pass
  that option, it would be more clear that it is a mistake, allowing
  a warning or even an error.

Of these three, the first seems most compelling to me.  Others may
have other ideas.

Thoughts?

Thanks,
Jonathan

  reply	other threads:[~2019-08-06  2:01 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 [this message]
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
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20190806020132.GB61803@google.com \
    --to=jrnieder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=lukasgross@u.northwestern.edu \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).