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

[David Kastrup <dak@gnu.org>]

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