Re: [PATCH] Documentation: --amend cannot be combined with -c/-C/-F.

Peter Eriksen <s022018@student.dtu.dk> wrote:

Hmm.  The log-message options to git commit seem confused to me.

The default behaviour is to fire up an editor for the user to provide a message. The editor buffer may be pre-initialized, e.g., because MERGE_MSG exists.

This default behaviour can be overridden in a number of ways:

  * -m forces the message to be its argument;
  * -F forces the message to be the contents of some file;
  * -C forces the message to be a copy of some other commit message.

So far, so good. One can see why all of these options are mutually exclusive. The problem is in the mess of other options like -c and --amend.

Currently -c (copy some other commit message, and then edit it) is considered to be a `force message to be...' kind of option, like the others I've listed above.

So, for some reason, is --amend. This last is really annoying. I frequently find that I end up typing

  VISUAL=: git commit --amend ...

to fix the stupid thing I forgot to do before I committed last time. No, dammit, I don't want to mess with the editor.

Somewhere in all of this is a fairly nice, regular set of operations trying to escape. There are two processes at work:

  * setting a default message, and
  * maybe getting the user to edit it.

The first part is slightly complicated: there are a number of places to get a default message from, and several might be possible:

  * explicitly specified by the user (e.g., -m);
  * found lying about in MERGE_MSG;
  * picked up from the HEAD commit (for --amend); or
  * empty.

Choosing between MERGE_MSG and --amend is difficult; indeed, they probably ought to be mutually exclusive. But both should obviously win over an empty initial message, and (I think) just as obviously lose to an explicit message -- after all, the purpose of --amend is primarily to replace the current HEAD commit, not to fill in a default message.

-- [mdw]