Daniel Vicarel [off-list ref] writes:
There are several git commands that take a "--continue"
option...`merge`, `rebase`, `cherry-pick`, etc. From looking through
the source though, only `merge --continue` seems to expect no other
arguments. Suppose that you have just resolved some merge conflicts,
and then want to run `git merge --continue --no-edit` to accept the
default merge commit message. Having to open/close the configured text
editor still is mildly annoying. I'm interested in submitting a patch
to "fix" this `merge` behavior, but I wanted to check if this was
really the intended behavior first, and if so why.
The answer lies somewhere between "it is very much deliberate" and
"'merge --continue' is so unimportant that nobody bothered".
Originally, our "merge" did not open an editor to give you a chance
to explain why you are merging a side branch when recording a
cleanly auto-resolved result. In fact, it didn't even have an
"--edit" option to optionally allow you to edit. This changed at
f8246281 (merge: use editor by default in interactive sessions,
2012-01-10); its log message is worth a read to understand the
issues.
Compared to a merge that cleanly auto-resolved, in a conflicted
merge, you have one more thing worth explaining to future readers of
"git log"---how and why the work on the side branch conflicted with
the work on the mainline, and how you chose to resolve it.
So, in that sense, we would very much want to do whatever possible
to encourage you to write a good log message. Opening an editor is
one step in that direction.
Among the commands with "--continue", "merge --continue" came much
later, and it did not even need to exist. The other commands with
"--continue", e.g. "rebase", deal with multi-step operations, and it
is worth to have a way to say "I am finished with this step, let's
CONTINUE WITH THE REST". But in "merge", there is no remaining
thing to do after you are done with the conflict you saw.
In hindsight, we probably should have resisted the urge to add
"merge --continue", just for the sake of misguided "consistency"
perceived on non-existent similarity with other commands that truly
need "--continue". What is called "merge --continue" should have
been called "merge --finish", if we needed to add something back
then.
The way to finish a conflicted merge has always been to run "git
commit" before "merge --continue" was added, and it still is not
just accepted but is the right way to finish a conflicted merge.
So, in that sense, "merge --continue" is so unimportant that it is
understandable that nobody bothered.
So I guess that makes two discouraging factors against adding
"--no-edit" to "merge --continue". It encourages a wrong behaviour
of under-explaining the result of your work, and "commit" is a much
shorter way to say "merge --continue" anyway.
In fact, "merge --continue --no-edit" is much longer to type than
"commit --no-edit".
merge --continue
commit --no-edit
Having said all that, among various things that the above discussion
suggests as possible next steps, i.e.
* deprecate and eventually remove "merge --continue"
* deprecate and eventually rename "merge --continue" to "merge --finish"
* add "--no-edit" to "merge --continue"
I think the last one might be the change with least impact and
resistance. Those who are unaware that "commit --no-edit" suffices
would end up typing a lot more and wasting their keyswitches' life,
but the damage is limited ;-)
Or we could throw in another
* document more clearly that "merge --continue" is a mere synonym
for, and hint that there is no reason to favor it over, "git
commit".
which happens to be my favourite so far after thinking the above
through.
Thanks.
Thank you so much for the detailed response! Brief side note...this is
my first time posting on the git mailing list (or any mailing list of
this kind!), so please educate me if I'm incorrectly quoting, using
reply/CC, or formatting lines (not sure if the mail server
automatically wraps lines after 72 chars)...
Junio C Hamano [off-list ref] writes:
Compared to a merge that cleanly auto-resolved, in a conflicted
merge, you have one more thing worth explaining to future readers of
"git log"---how and why the work on the side branch conflicted with
the work on the mainline, and how you chose to resolve it.
Fair point. I would argue that in my own personal projects, where I am
the only contributor, sometimes I just want to accept the default
merge message and move on. However, one could apply that reasoning to
_every_ commit message in a personal project, and I certainly don't
believe in that... so yeah, you've given me something to think about.
Junio C Hamano [off-list ref] writes:
The way to finish a conflicted merge has always been to run "git
commit" before "merge --continue" was added, and it still is not
just accepted but is the right way to finish a conflicted merge.
That makes sense. TBH, I assumed that `merge --continue` _was_ the
preferred way to finish merging after conflicts simply b/c the option
exists! `commit --no-edit` definitely meets my immediate needs though,
so thank you for that suggestion.
Junio C Hamano [off-list ref] writes:
[...] possible next steps, i.e.
* deprecate and eventually remove "merge --continue"
* deprecate and eventually rename "merge --continue" to "merge --finish"
* add "--no-edit" to "merge --continue"
[...]
* document more clearly that "merge --continue" is a mere synonym
for, and hint that there is no reason to favor it over, "git
commit".
I agree that some clearer documentation around `merge --continue` is
worthwhile, to prevent other developers from thinking like myself.
Maybe a warning from the CLI after running `merge --continue`,
recommending `commit` usage instead? Such a warning suggests that the
option _should_ still be deprecated and removed in the future though.
I am still interested in making a contribution to git, so let me know
which option you would like me to move forward with at this time:
adding the CLI warning, or going straight to a deprecation. Unless of
course you're already on it. :)
On Tue, Dec 21, 2021 at 12:13 PM Junio C Hamano [off-list ref] wrote:
Daniel Vicarel [off-list ref] writes:
quoted
There are several git commands that take a "--continue"
option...`merge`, `rebase`, `cherry-pick`, etc. From looking through
the source though, only `merge --continue` seems to expect no other
arguments. Suppose that you have just resolved some merge conflicts,
and then want to run `git merge --continue --no-edit` to accept the
default merge commit message. Having to open/close the configured text
editor still is mildly annoying. I'm interested in submitting a patch
to "fix" this `merge` behavior, but I wanted to check if this was
really the intended behavior first, and if so why.
The answer lies somewhere between "it is very much deliberate" and
"'merge --continue' is so unimportant that nobody bothered".
Originally, our "merge" did not open an editor to give you a chance
to explain why you are merging a side branch when recording a
cleanly auto-resolved result. In fact, it didn't even have an
"--edit" option to optionally allow you to edit. This changed at
f8246281 (merge: use editor by default in interactive sessions,
2012-01-10); its log message is worth a read to understand the
issues.
Compared to a merge that cleanly auto-resolved, in a conflicted
merge, you have one more thing worth explaining to future readers of
"git log"---how and why the work on the side branch conflicted with
the work on the mainline, and how you chose to resolve it.
So, in that sense, we would very much want to do whatever possible
to encourage you to write a good log message. Opening an editor is
one step in that direction.
Among the commands with "--continue", "merge --continue" came much
later, and it did not even need to exist. The other commands with
"--continue", e.g. "rebase", deal with multi-step operations, and it
is worth to have a way to say "I am finished with this step, let's
CONTINUE WITH THE REST". But in "merge", there is no remaining
thing to do after you are done with the conflict you saw.
In hindsight, we probably should have resisted the urge to add
"merge --continue", just for the sake of misguided "consistency"
perceived on non-existent similarity with other commands that truly
need "--continue". What is called "merge --continue" should have
been called "merge --finish", if we needed to add something back
then.
The way to finish a conflicted merge has always been to run "git
commit" before "merge --continue" was added, and it still is not
just accepted but is the right way to finish a conflicted merge.
So, in that sense, "merge --continue" is so unimportant that it is
understandable that nobody bothered.
So I guess that makes two discouraging factors against adding
"--no-edit" to "merge --continue". It encourages a wrong behaviour
of under-explaining the result of your work, and "commit" is a much
shorter way to say "merge --continue" anyway.
In fact, "merge --continue --no-edit" is much longer to type than
"commit --no-edit".
merge --continue
commit --no-edit
Having said all that, among various things that the above discussion
suggests as possible next steps, i.e.
* deprecate and eventually remove "merge --continue"
* deprecate and eventually rename "merge --continue" to "merge --finish"
* add "--no-edit" to "merge --continue"
I think the last one might be the change with least impact and
resistance. Those who are unaware that "commit --no-edit" suffices
would end up typing a lot more and wasting their keyswitches' life,
but the damage is limited ;-)
Or we could throw in another
* document more clearly that "merge --continue" is a mere synonym
for, and hint that there is no reason to favor it over, "git
commit".
which happens to be my favourite so far after thinking the above
through.
Thanks.
--
Dan Vicarel
On 21/12/2021 17:13, Junio C Hamano wrote:
Or we could throw in another
* document more clearly that "merge --continue" is a mere synonym
for, and hint that there is no reason to favor it over, "git
commit".
which happens to be my favourite so far after thinking the above
through.
Thanks.
I'm all for including the "document more clearly" approach...
With or without the code change.
--
Philip
On Tue, Dec 21 2021, Junio C Hamano wrote:
Or we could throw in another
* document more clearly that "merge --continue" is a mere synonym
for, and hint that there is no reason to favor it over, "git
commit".
But it's not:
$ git add foo
$ git commit -v
hint: Waiting for your editor to close the file.[...]
^C
$ git merge --continue
fatal: There is no merge in progress (MERGE_HEAD missing).
FWIW I prefer and use it for that reason, i.e. it's useful for scripting
to use these "stateful" commands when we're in some sort of rebase/merge
"sequence" since it's an extra layer of sanity checking.