git-commit --amend -m "..." complains?!?

I get

Option -m cannot be combined with -c/-C/-F/--amend.

but that makes no sense: of course there is ample reason for providing an amended commit message on the command line. -c, -C and -F indeed all provide an alternative commit message, but --amend doesn't.

So what is the beef?

David Kastrup <dak@gnu.org> writes:

The option --amend is about "reusing the original commit message and make amending edit on top". If you are restarting the message from scratch, --amend does not make much sense.

You can do:

	$ git reset HEAD^
        $ git commit -m "blah"

if you do not want to reuse the commit message.

Junio C Hamano <gitster@pobox.com> writes:

Uh no.  From the man page:

	--amend
	   Used to amend the tip of the current branch. Prepare the
	   tree object you would want to replace the latest commit
	   as usual (this includes the usual -i/-o and explicit
	   paths), and the commit log editor is seeded with the
	   commit message from the tip of the current branch. The
	   commit you create replaces the current tip -- if it was a
	   merge, it will have the parents of the current tip as
	   parents -- so the current top commit is discarded.

	   It is a rough equivalent for:

			    $ git reset --soft HEAD^
			    $ ... do something else to come up with the right tree ...
			    $ git commit -c ORIG_HEAD

	   but can be used to amend a merge commit.

The --amend is not, according to the manual page, there to amend the commit message, but primarily to amend the commit.

If one does not want to amend the message, this is easily done with -C HEAD. If one wants to amend the message but not by editing, one is plain out of luck.

-C, -F and -m are all logically exclusive (and -C -e is the same as -c). But --amend seems completely orthogonal to me with regard to the commit message: it just has a different seed from the normal commit message edit. You can override the seed with a normal commit using -c -C -F and -m. Why not with --amend?

It amends the _commit_. You can edit files, add them, and commit additional changes. If you are using a dumb terminal (or a system with nonworking VISUAL over the link in question), you don't _want_ an editor called up.

You can pretty much _always_ avoid --amend in a similar manner, but why would you? It is convenient.

David Kastrup <dak@gnu.org> writes:

No need to be upset about what I said. I really do not want to change the minor detail this late in the 1.5.3 release cycle, and wanted to unblock you by giving an workaround in case you were stuck.

It should be a straightforward change to git-commit.sh. Instead of "Oops, -m and --amend are incompatible so we will whine" around line 300, you can treat --amend somewhat specially by (1) making it first not set log_given, which would still keep the combination of -m/-c/-C/-F incompatible, (2) when $log_given is false and we are amending, honor $use_commit to prime the message. Then you can keep the current bahaviour for amending starting from the existing message, while allowing -m/-c/-C/-F to supply different message for the replacing commit.

Junio C Hamano <gitster@pobox.com> writes:

Well, there is always VISUAL='echo "mycommit" >"$1"' git commit --amend Uh, no wait, it isn't. Different thread.

I actually can't find anything about (2) to be done in the code.

In a somewhat different vein: it appears strange that -m is treated completely different from the other commit message specifiers: you can specify -m multiple times.

I have not changed this in the slightly tested patch posted separately: while the --amend fix was quite straightforward and confined (and indeed, not even the documentation appears to warrant any modification), the m/t mess is something I really don't want to mess with right now.

Signed-off-by: David Kastrup <dak@gnu.org>
---
 git-commit.sh |    5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

David Kastrup <dak@gnu.org> writes:

Ok, looks obviously correct.  Wasn't too painful, was it?

Thanks, will apply.