hIpPy venit, vidit, dixit 19.08.2017 00:35: > While merging if I do certain actions then the merge commit is made > with the merge message but as a normal (non-merge) commit. > > Repro steps: > - Set GIT_MERGE_AUTOEDIT=yes (set other than "no") in .bashrc > - Make a merge commit with no conflicts. > (external text editor shows the generated merge message) > - Focus on Git Bash and Ctrl-C. > - Commit (git commit). > > Actual behavior: > Git makes a normal (non-merge) commit (squash merge) but with the > merge commit message. > > It looks like a bug to me. This is very confusing later on as the repo > topology would show that the branch is not merged in and there is not > an easy way to find out when the merge was made. > > Expected behavior: > Git should stay in a MERGING state. The user can choose to either > abort the merge or continue the merge (git merge --continue OR git > commit). > > This does not happen in case of conflicts (at least I'm not able to > repro). I get a (master|MERGING) prompt till I resolve the conflicts > and commit, which goes through correctly as a merge commit. > > Environment: > $ git version > git version 2.14.0.windows.2 > $ bash --version > GNU bash, version 4.4.12(1)-release (x86_64-pc-msys) Thanks for the detailed info! It turns out that his is not Windows specific. The recipe is: - make "git merge" call and wait for an editor - kill "git merge" while it waits for the editor The effect is that prepare_to_commit() has no chance to call abort_commit() any more (which would call write_merge_state()).. Now, I'm not sure why we only do half of write_merge_state() (write out the merge_msg, but not merge_head) before launching the editor. In any case, the following patch solves the problem and passes the existing tests. But I'll wait for more comments (and think about a test meanwhile). Michael
