Hi,

quoted text
> <gitster@pobox.com> wrote:
> > Following git tradition, manpage came after the command's behaviour has
> > been long established.  It will be a behaviour change, and it is open to
> > debate if the new behaviour is better or if the proposed change of
> > behaviour hurts existing users.
> 
> If my opinion counts, I like the current ("prepend") one, and I think
> the best would be to add a new option (and/or make it configurable) for
> the new ("replace") one.

Well, perhaps I am different, but I sometimes have temporary branches
named like "first-silly-experiment" and I do not expect having a
    Merge branch 'another-silly-experiment' into 'first-silly-experiment'
appended, when I do a
    git merge -m "Merge a lot of useful stuff... blabla" another-silly-experiment.

(btw, I don't *really* name my branches like this..it's just an example.)

Well, I see this from a "sequencer author point of view", where
     merge silly-experiment
will invoke an editor,
     merge --standard silly-experiment
generates some kind of the typical standard (or default) message,
and
     merge --message "Merge blabla" silly-experiment
does the "obvious". (For me this is the obvious since I've never
experienced another behavior. All my merges have been using the
now disappeared commit.)

So I'd vote for a "replace" behavior by default on -m, and an 
"append standard message" option, but if there is *one* person
who relies on the prepend feature, I'd also take the "prepend"
default and would like to vote for an option that does the
replacement.

For the current state of the art, it seems that I have to merge
with whatever message and then do a commit -m "..." --amend.

Regards,
  Stephan Beyer

PS: Currently using webmail. So sorry for any too long lines
or whatever.
-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html