Daniel Vicarel <shundra8820@xxxxxxxxx> writes: > Thanks for the input, all. > > Junio C Hamano <gitster@xxxxxxxxx> writes: >> 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 <gitster@xxxxxxxxx> writes: >> coming up with a sensible list of allowed options and arguments [to `git merge --continue`] would be quite hard. > > Chris Packham <judge.packham@xxxxxxxxx> writes: >> 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.
