From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:50
Miklos Vajna [off-list ref] writes:
On Fri, Jun 27, 2008 at 07:19:48PM +0200, Stephan Beyer [off-list ref] wrote:
quoted
-m <msg>::
The commit message to be used for the merge commit (in case
it is created). The `git-fmt-merge-msg` script can be used
to give a good default for automated `git-merge` invocations.
So it is not mentioned that a standard message is appended, and thus the
original behavior is somehow "buggy" :)
Ah, OK. Then the code and the documentation differs and that's a bug,
sure.
From git-merge.sh:
# All the rest are the commits being merged; prepare
# the standard merge summary message to be appended to
# the given message.
I did builtin-merge based on git-merge.sh, not the manpage. ;-)
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.
On Fri, Jun 27, 2008 at 02:28:29PM -0700, Junio C Hamano [off-list ref] 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.
From: Stephan Beyer <hidden> Date: 2016-06-15 22:44:51
Hi,
[off-list ref] wrote:
quoted
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
From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:51
Miklos Vajna [off-list ref] writes:
On Fri, Jun 27, 2008 at 02:28:29PM -0700, Junio C Hamano [off-list ref] wrote:
quoted
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,...
Well, I do not think you are alone --- otherwise the original behaviour
would not be such ;-)
In any case, what is more important is that the proposed change is a
change in behaviour and the burden of proof that it does not hurt people's
existing scripts is on the party that wants to change it.