On Wed, Mar 13, 2019 at 8:29 PM Duy Nguyen <pclouds@xxxxxxxxx> wrote: > > 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 You cannot yet do this with merge_recursive; it writes conflicts to the worktree as it goes and doesn't tell you whether the merge was successful or had conflicts until its done. So this would be very dangerous. We'd first need a way to do an in-memory merge that doesn't touch the working tree or index and which gives you the opportunity to check whether that worked before proceeding to write out any updates. That is work I plan to do (for other reasons), but not in progress currently. > to continue) while allowing succesful 3-way merges by default. But are > successful 3-way merges reversible? Hmm, interesting. So, switching from branch A to B, you start with local changes on top of A that could represent a virtual commit C. So, you three-way merge C & B using A as the base. It's clean, so we have a new endpoint, call it D. Switching back to A with the --merge flag would mean a three-way merge of D & A using B as the base. But it might be easier if I re-labelled all of these with different terms. Let's say we squash all changes from A to B into a single commit on top of A that we call commit B. Check out C (a commit representing your local changes on top of A), and cherry-pick B; that will three-way merge C & B using A as the base. It's clean, so we have a new commit, call it D. Now we tell git to revert B, which will do a three-way merge of D (current HEAD) & A (parent of B), using B as the base. So, essentially, your question about reversibility boils down to: if you can cleanly cherry-pick a commit to your current branch, can you then immediately revert that same commit on top to return to where you were before? (Off the cuff, I _think_ the answer to that is yes due to the assumption that the cherry-pick was without conflicts, but I'm not immediately sure.)
