Prompt for merge message?

I often find myself using "--no-ff -m foo" for merging short-lived branches, because the merge commit usually needs to say something about having finished a feature rather than referring to a branch that will be deleted shortly anyway. However, it's a little annoying to have to always write the commit message on the command-line, especially in cases where a more expository multi-line message would be useful.

Is there currently a way to get git to prompt for the merge message, rather than using the default or requiring the -m flag? If not, isn't this a common-enough use case to have that ability added to the merge function?

On Thu, 06 Oct 2011 10:49:02 -0700, Todd A. Jacobs wrote:

"git merge --no-ff --no-commit branch_foo && git commit" ?

Though it would be handy to have a "stop and let me edit the merge commit message" flag on git merge itself.

In message <20111006182534.GA13628@vfa-6h>, Jacob Helwig writes:

    On Thu, 06 Oct 2011 10:49:02 -0700, Todd A. Jacobs wrote:

    > I often find myself using "--no-ff -m foo" for merging short-lived
    > branches, because the merge commit usually needs to say something
    > about having finished a feature rather than referring to a branch that
    > will be deleted shortly anyway. However, it's a little annoying to
    > have to always write the commit message on the command-line,
    > especially in cases where a more expository multi-line message would
    > be useful.

    "git merge --no-ff --no-commit branch_foo && git commit" ?

While not ideal, you can use a multi-line message on the command line. I do it all of the time. Popping up an editor like in the separated workflow is more user friendly.

---------------------------------------------------------------------- git merge --no-ff -m "My feature is very complex

It requires multiple lines to explain.

Or perhaps I am too verbose." branch_foo ----------------------------------------------------------------------

					-Seth Robertson

----- Original Message -----

And not so helpful if you want to use the --log option to pre-populate the merge message (which I often run into).

Thanks, Stephen

On Thu, 06 Oct 2011 11:25:34 +0000, Jacob Helwig wrote:

"git merge --no-ff branch_foo && git commit --amend"

Andreas

"Todd A. Jacobs" <nospam+listmail@codegnome.org> writes:

Others commented on the current practices and gave their own useful tips already, but an additional hint is to name your branch more sensibly, so that you do not feel it is useless to record it in the history.

As to a real longer-term solution, I wouldn't mind a patch that teaches "git merge" an "-e" option just like "git commit" has.

    $ git commit -m "Finish frotz feature" -e -a
    ... editor opens with the first line filled already here ...

is something I find myself using fairly often.

Thanks.

[offtopic: It is annoying that my MUA warns me

    "nospam+listmail@domain" may be bogus; do you really want to send?

Could you do something about it please?]

On Thu, Oct 6, 2011 at 15:02, Junio C Hamano <gitster@pobox.com> wrote:

What about adding something like:

  if (isatty(0) && isatty(1) && isatty(2)) {
    do_interactive_commit();
  }

to git merge? I know the reason we don't want to do it all of the time is because git merge is already used in a lot of scripts. But how many of those are running with an active terminal on all 3 standard fds when it runs git merge?

Shawn Pearce <spearce@spearce.org> writes:

Ninety four?

$ git grep -l 'git merge' -- 't/t[0-9][0-9][0-9][0-9]-*.sh' | wc -l

On Oct 6, 6:02 pm, Junio C Hamano <gits...@pobox.com> wrote:

While I can see your point of view, I don't think that it fits every work-flow. In particular, if you want to maintain a linear history on the master branch but record the completion of a feature as a commit object separate from the last patch in a series, you have two choices at the moment:

1. A fast-forward merge, followed by an empty commit with --allow-
empty. However, the empty commit seems to get discarded on merges, or
finds other ways to disappear outside of the feature branch on which
it was created. It probably isn't a bug, but it can be very surprising
to create an empty commit object on a feature branch, and then have it
disappear when you merge to master.

2. A merge commit with an explicit merge message, which is what we've
been talking about in this thread.

The point of the exercise is (mostly) to integrate with issue trackers like Pivotal or GitHub, where a commit with certain keywords can integrate with ticket history. But, IMHO, it doesn't necessarily make sense that any given patch closes a ticket; sometimes they do, but sometimes I really prefer a standalone commit to essentially say "and now the ticket is really, really done."

The fact that there have been so many useful suggestions about how to work around this issue seems to imply that it isn't a low bus-factor issue. My personal vote is for your suggestion of an [-e|--edit] flag for the merge; that would make it (mostly) consistent with commit's behavior. I can certainly see that in the common case the default merge message is the right thing to do, but I really do feel that there ought to be *some* flag to allow a visual editor to edit the merge message without having to amend the merge commit or merge without a commit just so that the next commit will invoke the editor.

Ultimately, I guess what I'm really agitating for is just an editor option for merge commits. If you take work-flow out of the equation, isn't there still a case for easily-editable merge messages?

"Todd A. Jacobs" <nospam+listmail@codegnome.org> writes:

I do not see any reason for you to be agitated. All you need to do is to read beyond what you chose to quote from my message, read that part before omitting from your quote ;-).