Re: Why does "merge --continue" expect no arguments?

Daniel Vicarel [off-list ref] writes:

Thanks for the input, all.

Junio C Hamano [off-list ref] writes:

quoted

perhaps the doc update would be the quickest one that offers the most to learn from

Sounds good! Now by "doc update" do you mean updating docs in the
Documentation/ folder, or adding a warning to the CLI output of `git
merge --continue`?

The former.  The current text says "... you can conclude the merge
by running `git merge --continue`" without giving a clue that this
is another way to say "git commit" that is longer to type.

The way it rejects extra arguments happens to work as a safety valve
that is not very end-user friendly; as you found out, it rejects
options and arguments (like pathspec).  So "--continue" is more than
a mere synonym to "git commit".

Junio C Hamano [off-list ref] writes:

quoted

coming up with a sensible list of allowed options and arguments [to `git merge --continue`] would be quite hard.

Chris Packham [off-list ref] writes:

quoted

I think it'd be a good idea to allow [--no-edit on `git merge --continue`] as long as it's the only other option allowed with --continue.

Based on these two pieces of feedback, it sounds like adding _just_
the `--no-edit` option at this point to `git merge --continue` is
worthwhile, and hopefully approachable for a newb. For now I'll put a
pin in it though, and focus on the documentation task above.

Well, I don't know about Chris, but I didn't mean to suggest that by
saying that deciding which ones to allow and which ones to reject is
hard.  Knowing that there are other options that deserve the same
attention as `--no-edit` to be supported now makes a patch to only
add support for `--no-edit` an incomplete one.  If we need to add
support for more in the future, at least the mechanism used to add
the first one should be something we can reuse in the future for
these other ones.

The way "git commit" is internally invoked from "git merge --continue"
happens to work with the current "we only pass no arguments, and we
exit once the command is done" usage, but it fundamentally is wrong.
No cmd_foo() functions should be called from anything but the
run_builtin() function in git.c, as they are not prepared to be
called twice, and they are not prepared to be called in an
environment where other things (like reading configuration files)
have already happened.  If we were to extend what is passed when
"git merge --continue" calls "git commit", we should first clean up
the (ab)use of cmd_commit() call from the code path, before adding
new features.

So, no, I do not think it is a welcome change to just allow passing
"--no-edit" in a way that is "approachable for a newb".

Thanks.