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

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

[David Kastrup]

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

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

[Junio C Hamano]

David Kastrup <dak@gnu.org> writes:

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

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.

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

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
>> 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.
>
> The option --amend is about "reusing the original commit message
> and make amending edit on top".

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?

> If you are restarting the message from scratch, --amend does not
> make much sense.

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 do:
>
> 	$ git reset HEAD^
>         $ git commit -m "blah"
>
> if you do not want to reuse the commit message.

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

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Junio C Hamano]

David Kastrup <dak@gnu.org> writes:

> Junio C Hamano <gitster@pobox.com> writes:
> ...
>> You can do:
>>
>> 	$ git reset HEAD^
>>         $ git commit -m "blah"
>>
>> if you do not want to reuse the commit message.
>
> You can pretty much _always_ avoid --amend in a similar manner, but
> why would you?  It is convenient.

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.

[PATCH] git-commit.sh: Permit the --amend message to be given with -m/-c/-C/-F.

[David Kastrup]

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

diff --git a/git-commit.sh b/git-commit.sh
index 4290ae2..d7e7028 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -190,7 +190,6 @@ $1"
 		;;
 	--a|--am|--ame|--amen|--amend)
 		amend=t
-		log_given=t$log_given
 		use_commit=HEAD
 		shift
 		;;
@@ -298,9 +297,9 @@ esac
 
 case "$log_given" in
 tt*)
-	die "Only one of -c/-C/-F/--amend can be used." ;;
+	die "Only one of -c/-C/-F can be used." ;;
 *tm*|*mt*)
-	die "Option -m cannot be combined with -c/-C/-F/--amend." ;;
+	die "Option -m cannot be combined with -c/-C/-F." ;;
 esac
 
 case "$#,$also,$only,$amend" in
-- 
1.5.3.rc2.84.gd0bef-dirty

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

[David Kastrup]

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

> David Kastrup <dak@gnu.org> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>> ...
>>> You can do:
>>>
>>> 	$ git reset HEAD^
>>>         $ git commit -m "blah"
>>>
>>> if you do not want to reuse the commit message.
>>
>> You can pretty much _always_ avoid --amend in a similar manner, but
>> why would you?  It is convenient.
>
> 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.

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

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

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

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

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.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: [PATCH] git-commit.sh: Permit the --amend message to be given with -m/-c/-C/-F.

[Junio C Hamano]

David Kastrup <dak@gnu.org> writes:

> Signed-off-by: David Kastrup <dak@gnu.org>
> ---
>  git-commit.sh |    5 ++---
>  1 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/git-commit.sh b/git-commit.sh
> index 4290ae2..d7e7028 100755
> --- a/git-commit.sh
> +++ b/git-commit.sh
> @@ -190,7 +190,6 @@ $1"
>  		;;
>  	--a|--am|--ame|--amen|--amend)
>  		amend=t
> -		log_given=t$log_given
>  		use_commit=HEAD
>  		shift
>  		;;
> @@ -298,9 +297,9 @@ esac
>  
>  case "$log_given" in
>  tt*)
> -	die "Only one of -c/-C/-F/--amend can be used." ;;
> +	die "Only one of -c/-C/-F can be used." ;;
>  *tm*|*mt*)
> -	die "Option -m cannot be combined with -c/-C/-F/--amend." ;;
> +	die "Option -m cannot be combined with -c/-C/-F." ;;
>  esac
>  
>  case "$#,$also,$only,$amend" in

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

Thanks, will apply.