On 25/07/22 01:54PM, Junio C Hamano wrote: > Justin Tobler <jltobler@xxxxxxxxx> writes: > 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. In general, I think it is best to reserve short flags for relavitely common operations. That way, if a new super useful option were to be introduced that we want a short flag for, there is a better chance a good flag choice will be available. That being said, I incorrectly assumed `--merge` was an uncommon option. If there are workflows that make frequent use of this option, we should drop this patch and keep the short flag available. > > 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. That's fair. If we do want to keep this patch, we could still keep it as part of `builtin/checkout.c:add_common_options()`, but add an argument to toggle short flag usage. This way it is at least clear to readers of the code that it is same option. Thanks, -Justin
