On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote: > > +-m:: > > +--merge:: > > + If you have local modifications to one or more files that are > > + different between the current branch and the branch to which > > + you are switching, the command refuses to switch branches in > > + order to preserve your modifications in context. However, > > + with this option, a three-way merge between the current > > + branch, your working tree contents, and the new branch is > > + done, and you will be on the new branch. > > I was wondering what people felt about making this the default for the > new command. If I'm carrying changes over to the new branch then I want > them to be merged in, it's annoying to have them carried over most of > the time but then sometimes have the checkout fail without specifying > --merge. If my worktree has local changes and I accidentally switch to a different branch, I could switch back without losing any local changes and the tree I have is exactly what I had before the switch. Is this still true if -m is made default? I think sometimes a 3-way merge creates marker conflicts in file, and this does not look easy to reverse when switching back. If it's true and we can detect it, we can still abort this case (i.e. requiring -m to continue) while allowing succesful 3-way merges by default. But are successful 3-way merges reversible? -- Duy
