Justin Tobler <jltobler@xxxxxxxxx> writes: > Both git-switch(1) and git-restore(1) inherit some common options from > git-checkout(1). One such option is the `--merge` flag and its > accompanying short flag `-m`. > > In previous discussion[1] around removing the experimental marker for > git-switch(1), it has been suggested that this short flag could instead > be used for an option similar to `--move` from git-branch(1). Such a > feature is not yet implemented for this command, but reserving a short > flag for an uncommon option is unnecessary and hinders potential future > extension. > > While these commands are still marked as experimental, remove the `-m` > flag from both git-switch(1) and git-restore(1) and update the > documentation accordingly. Surely the whole point of marking the commands as experimental is to allow us to make a change like this one. I doubt that this particular one is a sensible change, though. "git checkout -m <another-branch>" is one of the most frequently used operation in my daily workflow, and having to type "git switch --merge" (not having to learn to do so) would be a major annoyance. > The `--conflict` flag is also now defined > explicitly for each command as to remain alongside its related `--merge` > companion. I doubt this is a wise move. Unless we are planning to make the option diverge across these three commands, that is. The main logic that implements the "move to a different branch, while merging local changes into the new base" does use these two things together in the same code path (in merge_working_tree()). The same for "check out a single path out to the working tree", which does use these two things together in the same code path (in checkout_merged()). I actually think keeping it in the common part would help the readers of the code even more---by making it clear that these three commands parse the option exactly the same way.
