Why did git merge --no-commit add a commit to my history when I unstaged?

Question

I was working on a branch, and realized that I wanted changes from a different branch to help with my testing, but I didn't want to actually commit them to my current branch. So I used git merge --no-commit to bring those changes into my current branch. Then I unstaged the changed files with git reset and proceeded with my work and testing. Eventually I committed some changes related to my current work (but not the changes related to the other branch that I had brought in and unstaged).

I was confused to find that the commit history for my current branch now shows a commit from the "other branch" even though I never committed those changes here. I don't seem to actually have the changes, but looking through the log is confusing because it appears the changes were applied (and never removed) but they aren't here. So I think I got what I want in the end, but with a confusing history.

I realize now that what I did was presumably not a good way to accomplish my goals, but can anyone help me understand how the history works? I suppose there's some chance that I am misremembering exactly what I did too...

EDIT: Here's the most recent part of my git log graph. The part I don't understand now is why the actual changes from commit 34eaa54 do not appear at the head of my journal branch.

* 1c2e2d4 (HEAD -> journal, origin/journal) fix: make command consistent
* 4bedc14 fix: remove space
*   03499a4 fix: use subprocess instead
|\
| * 34eaa54 (origin/update, update) feat: use mock images
* | a8be334 feat: save journal
|/
*   8560394 (tag: v0.2.14, origin/master, origin/HEAD, master) Merge branch 'fix-timeout' into 'master'

EDIT2: Add reproducible example. If you follow these instructions then you can see at the end that you will have the half-aborted commit "in" branch-one but the change isn't there (the word rabbit). The included git status command explicitly mentions still being in the merge, despite the fact that I reset the changed file, so, as expected, that seems to be "why" this happens.

printf "the\nquick\nbrown\nfox\n" > a
git init
git add a
git commit -m "initial commit"
git checkout -b branch-one
sed -i 's/quick/fast/g' a
git add a
git commit -m "fix: fast"
git checkout master
git checkout -b branch-two
sed -i 's/fox/rabbit/g' a
git add a
git commit -m "fix: rabbit"
git checkout branch-one
git merge --no-commit branch-two
git reset -- a
touch b
git add b
git status
git commit -m "feat: add b"
git reset --hard
git log --graph --oneline
cat a

Answer 1

git merge --no-commit starts a merge operation, then stops in the middle.

A subsequent git merge --continue first verifies that you're still in the middle of the incomplete merge, then completes it by running git commit.

A subsequent git commit instead of git merge --continue ... completes the merge, as if you'd run git merge --continue, because you are still in the middle of the incomplete merge.

The git log command takes history, i.e. commits—including merge commits, which inherently make history non-linear—and shows you commits one at a time. To see how they relate, historically, use git log --graph, or git log --oneline --graph for a more compact form. See also Pretty Git branch graphs.

Fixing the mess (if it's a mess and you don't like it)

If you did not want a merge commit here, consider using git reset and git cherry-pick:

• If you have uncommitted work, commit it.

• Now create a branch or tag name where you are now, so that Git will remember commit hash IDs for you, using the name you create now. (If you don't do this, you have to find hash IDs, which is no fun.) For instance:

  git branch save-this
  

  will create a new branch named save-this; you'll be able to run git log save-this to see commits.

• Then use git reset --hard with a commit hash ID, or some origin/* name, or whatever, to make your current branch no longer have the commits you've made.

• Now you can use git cherry-pick, one commit at a time, to pick up commits from the branch named save-this. When you get to the commit that is a merge, but should not have been a merge, use git cherry-pick -m with a number (1 or 2) to cherry-pick only some of the commits. You almost always want the number 1 here (git cherry-pick -m 1 hash). For the non-merge commits, leave out the -m option and the number: -m is only useful on merge commits (where it's required); it's forbidden for non-merge commits.

Once you have the desired commits—the new ones are new, with different hash IDs, and presumably are better than the old ones since they now have what you want in them—you can delete the save-this branch. (You can leave it around as long as you like, in case you're not sure yet. Delete it when you're sufficiently sure. You can rename it, e.g., git branch -m save-this old-saved-stuff, or whatever you like, any time you like, too.)