Re: [git-users] More on that "merge branch checkout" problem -- cannot abort/go back?

Re: [git-users] More on that "merge branch checkout" problem -- cannot abort/go back?

[Michael]

This is going to the main git list. I had an issue with a git gui checkin, where I did a checkin of selected lines (no problem), then tried to switch branches and check in the rest.

Things broke.

I attempted to get help on the git users list, but was unable to.

To recap what happened:
1. I started on develop.
2. I made a feature branch.
3. I did some stuff. About half would be checked in on the feature branch, and about half on a "code cleanup" branch.
4. One hunk in the diff was a close comment (for the code cleanup) and then a bunch of new stuff (For the feature).
5. I used git gui to select what portions I wanted to check in.
6. In the past, using git gui to check in some lines of a hunk in one commit, and the other lines in a succeeding commit _on the same branch_ did not give me trouble. But this time, I was switching branches in between.
7. Git checkout complained about my changes being overwritten. git checkout -m did "work", but complained about a merge conflict.
8. There was no way to switch back -- there was no merge to abort, and no way to recover the previous state.

What I don't understand is:
1. Why is there no way to abort a merge checkout, and
2. Why was it that I could check in a portion of a hunk in git gui, but then not switch without a conflict? I'm not asking why there was a conflict as reported by diff -- I checked in the bottom half of a hunk, and kept "not checked in" the top half, so the context lines would not match. I'm asking more like, why wasn't git able to tell that the other part of the hunk was already checked in, and what I wanted to keep here was the stuff that was not checked in -- the "live git diff" which only showed the close comment in that part of the diff. 

To clarify #2: The three versions in the conflict file were "nothing" (the old develop that had none of these changes), "what was checked in" (the feature branch), and "everything"; what I wanted was "everything - what was checked in" (which is what git diff reported before I switched branches).

On 2017-01-30, at 5:45 PM, Michael <keybounce@gmail.com> wrote:

> 
> On 2017-01-29, at 11:32 PM, Konstantin Khomoutov <flatworm@users.sourceforge.net> wrote:
> 
>> On Sun, 29 Jan 2017 11:07:34 -0800
>> Michael <keybounce@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. ;-)
> 
> I still don't understand "--ours" or "--theirs" on checkout.
> 
> I also am not sure that any of them are what I want. The three "versions" at the merge hunk were:
> 1. Nothing (this was the previous 'develop' branch tip)
> 2. The stuff that was added in the checkin on the other branch (this was the previous 'feature' branch tip)
> 3. Everything, the close comment AND the stuff added (this was the whole conflicted hunk)
> 
> What I needed was basically "whole hunk - stuff checked in on feature". And since the file had other things that merged in just fine (an open comment earlier up), neither version (ours or theirs) could be the right version, even if I could restrict it to just the conflicted hunk.
> 
> Where should it roll back to? Where I was before. There's a ref (I think it's MERGE_HEAD) created to allow you to abort a merge back to where you were, so why not a CHECKOUT_HEAD (or, if it's doing a 3-way merge, why not record the full merge information?)

---
Entertaining minecraft videos
http://YouTube.com/keybounce