Re: [PATCH 1/2] builtin: remove merge short flag for switch and restore

[Junio C Hamano <gitster@pobox.com>]

Justin Tobler <jltobler@gmail.com> 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.