Git development
 help / color / mirror / Atom feed
From: Mark Wooding <mdw@distorted.org.uk>
To: git@vger.kernel.org
Subject: Re: [PATCH] Documentation: --amend cannot be combined with -c/-C/-F.
Date: Thu, 25 Jan 2007 12:29:30 +0000 (UTC)	[thread overview]
Message-ID: <slrnerh8la.7v0.mdw@metalzone.distorted.org.uk> (raw)
In-Reply-To: 20070124195446.GA13817@bohr.gbar.dtu.dk

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

> We used to get the following confusing error message:
>
> % git commit --amend -a -m foo
> Option -m cannot be combined with -c/-C/-F

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]

  reply	other threads:[~2007-01-25 13:17 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-24 19:54 [PATCH] Documentation: --amend cannot be combined with -c/-C/-F Peter Eriksen
2007-01-25 12:29 ` Mark Wooding [this message]
2007-01-25 22:21   ` Junio C Hamano
2007-01-25 22:38     ` Matthias Lederhofer

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

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

  git send-email \
    --in-reply-to=slrnerh8la.7v0.mdw@metalzone.distorted.org.uk \
    --to=mdw@distorted.org.uk \
    --cc=git@vger.kernel.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox