On Sun, 29 Jan 2017 11:07:34 -0800 Michael <keybou...@gmail.com> wrote:
> So since my attempt to switch branches with the "merge" flag (-m) > gave me an error, I thought I'd try to go back. > > keybounceMBP:Finite-Fluids michael$ git merge --abort > fatal: There is no merge to abort (MERGE_HEAD missing). > keybounceMBP:Finite-Fluids michael$ git status > On branch cleanup > Unmerged paths: > (use "git reset HEAD <file>..." to unstage) > (use "git add <file>..." to mark resolution) > > both modified: > src/main/java/com/mcfht/realisticfluids/fluids/BlockFiniteFluid.java > > Changes not staged for commit: > (use "git add <file>..." to update what will be committed) > (use "git checkout -- <file>..." to discard changes in working > directory) > > modified: > src/main/java/com/mcfht/realisticfluids/FluidData.java modified: > src/main/java/com/mcfht/realisticfluids/commands/CommandEnableFlow.java > modified: > src/main/java/com/mcfht/realisticfluids/fluids/BlockFiniteLava.java > > no changes added to commit (use "git add" and/or "git commit -a") > > I'm not saying this is necessarily wrong (the other branch does have > everything, and I'm on a branch where I could just commit all these > changes now, and worry about fixing it later; no data would be lost), > but I do think that it breaks the user's reasonable beliefs about > what the system does -- including the ability of a version control > system to roll back to a prior state (which in this case it cannot -- > or if it can, I don't know how.) To cite the documentation: | -m, --merge | When switching branches, 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. | | When a merge conflict happens, the index entries for conflicting | paths are left unmerged, and you need to resolve the conflicts and | mark the resolved paths with git add (or git rm if the merge should | result in deletion of the path). | | When checking out paths from the index, this option lets you recreate | the conflicted merge in the specified paths. So I'd say your best bet is to run git checkout --ours path/in/conflict on conflicting paths. As to your idea, I find it to be sensible but in fact you did not attempt true merge, and hence asking for aborting it is dubious. Maybe `git checkout --abort` would have more sense? But then the question is: what state should it roll your back to? Should it revert switching on a new branch as well? Please consider bringing this question on the main Git list to solicit insight of those with mad Git skillz. ;-) -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
