Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: >> Why modify tests? I think "git merge --continue" is a nice idea, >> and I don't see how it's inconsistent in any way with continuing to >> allow old practice. I agree. Updating the test will hide a regression if Ram's update breaks the existing workflow to conclude a conflicted merge with "git commit". If we are to add "git merge --continue" sugarcoat to make it easier to teach new people saying that "To any Git operation that stops and asks you to help, you can tell it that you are done helping by re-running the same command with --continue flag", then _new_ tests should be added to make sure that "git merge --continue" does act just like "git commit" in such a case. > In the future, we might want a 'merge' instruction in the sequencer -- The end-user facing frontend may be "git rebase" in such a case, and we would be teaching the users "When you are done helping the conflicted 'rebase', tell it that you are done by running 'rebase --continue'". The command verb 'merge' on the sequencer insn sheet does not have any direct connection to 'git merge' command (e.g. 'pick' does not have to be and is not implemented using 'git pick' command that does not exist). So I do not think we would ever say "merge --continue" in this context to begin with. >> As Junio hinted, it could make a lot of sense for "git cherry-pick >> <single commit>" to not create sequencer state in the first place. >> "git cherry-pick --continue" does not need it --- it is enough to >> commit with the conflict resolved. "git cherry-pick --abort" does not >> need it, either --- it is enough to "git reset --merge HEAD". > > Okay, here's my problem with the idea: it'll essentially require the > sequencer to differentiate between one-commit operations and > many-commit operations. I think you are looking at it in a wrong way. It is just about giving backward compatibility to historical hacks. cherry-pick and revert may be the only ones needed, and a new command Foo that implements its workflow in terms of the sequencer can choose to (and should choose to unless there is a compelling reason not to, because of the exact reason you stated here) do a single-command insn sheet with "git Foo --continue" to conclude if that one and only step needed help from the end user. "git am" would fit in the picture the same way. The sequencer insn sheet it would produce would consist of "patch <filename>" or something, and after the last one of them fails, the user would fix things up in the working tree, "git am --continue" will create a commit, and because there is no more steps in the sequence, the sequencer state will be removed. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html