在`git format-patch`，`git am`，`git pull`之后，在git历史中提交了两次提交

Question

I develop code on my PC, and I have few computing nodes.

To keep my programs synced I decided to use git. Formerly I used it in a one-way mode to "push-down" changes from PC to computing nodes. However from time to time I encountered small bugs that were specific to computing nodes and fixed it on-site. It was easier to test and develop, than writing on PC and committing a change that might or might not have fixed everything.

I decided to use git utilities to send the changes back up-stream into main code base.

I coded fix. Committed it on the computing note, used git format-patch origin . Sent patch to my PC and applied it with git am . Up to this point everything looked pretty sweet.

However, when I used git pull on the computing node it pulled the commit with patch from origin again and git log shows two commits with the same comments and authors.

Have I used commands wrong, or my workflow is flawed? Or this is acceptable? (However it doesn't look good to me).

I worked on master branches in both cases.

git pull computing node:

commit 68710f82ddb2b2f191a9c29f088423853032a851  <--- git pull enforced merge
Merge: ce19df4 609b82b
Author: luk32 <luk32@computing.node>
Date:   Fri Dec 13 20:39:28 2013 +0100

    Merge branch 'master' of PC:~/projects/_cmake

commit 609b82bc96f88da956869cec2953e8621cbdcd93  <--- 2nd git pull after git am
Author: luk32 <luk32@computing.node>
Date:   Fri Dec 13 20:35:23 2013 +0100

    Changed to worki with MathGL version 2. Broken version 1 compatibility!

commit ce19df4760519eaf42269461f7bdcf94b65bdc48  <--- on-site fix
Author: luk32 <luk32@computing.node>
Date:   Fri Dec 13 20:35:23 2013 +0100

    Changed to worki with MathGL version 2. Broken version 1 compatibility!

commit ccc5b8a1854e4ca4089cf4c0945baff990288557  <--- after previous git pull
Author: lukas <luk32@PC>
Date:   Mon Jan 16 10:33:11 2012 +0100

    skeleton changed to introduce project stacks

git log on PC looks fine:

commit 609b82bc96f88da956869cec2953e8621cbdcd93
Author: luk32 <luk32@computring.node>
Date:   Fri Dec 13 20:35:23 2013 +0100

    Changed to worki with MathGL version 2. Broken version 1 compatibility!

commit ccc5b8a1854e4ca4089cf4c0945baff990288557
Author: lukasz kucharski <luk32@PC>
Date:   Mon Jan 16 10:33:11 2012 +0100

    skeleton changed to introduce project stacks

EDIT: computing.node:~/projects/_cmake$ git log --decorate --graph --oneline master

*   68710f8 (HEAD, master) Merge branch 'master' of PC:~/projects/_cmake
|\  
| * 609b82b (origin/master, origin/HEAD) Changed to work with MathGL version 2. Broken version 1 compatibility!
| * ccc5b8a skeleton changed to introduce project stacks
* | ce19df4 Changed to work with MathGL version 2. Broken version 1 compatibility!
|/  
* 35d2eaa (origin/pushee) added eigen3 find module
* 39f4937 small bugfixes and slight changes in the reporting of what's going on

Answer 1

After you applied the patch to origin and before you ran git pull , your history looked like this:

  * 609b82b (origin/master, origin/HEAD) Changed to work with MathGL version 2. Broken version 1 compatibility!
  * ccc5b8a skeleton changed to introduce project stacks
* | ce19df4 (HEAD, master) Changed to work with MathGL version 2. Broken version 1 compatibility!
|/
* 35d2eaa (origin/pushee) added eigen3 find module
* 39f4937 small bugfixes and slight changes in the reporting of what's going on

Your first commit, ce19df4 , has 35d2eaa as its parent. When you applied the patch, you made a second commit, 609b82b , with ccc5b8a as its parent. Because they have different parents, they are different commits and have different hashes. The identity of a commit is an agragate of

• A snapshot of the repository (different in the second commit since the repository now has the changes from ccc5b8a in it).
• The commit message, author, time (the same since you used format-patch and am ).
• The parent commit (different in the second commit).

So, what does git pull do? I don't teach pull to new git users, because it's confusing. It depends upon the branch you are on and only works if it's setup as a tracking branch ( master probably will be, but likely not your other branches unless you set them up yourself). It does two things:

• Fetches remote changes (same as git fetch ).
• Tries to merge the remote branch with your current branch (same as git merge ). It only knows what branch to try and merge with if your local branch is set up as a tracking branch.

The merge is what's confusing. It tries to do a fast-forward merge ( read more here ), but can't. So, instead, it creates a merge commit with your local branch as one parent and the remote branch as another parent and you get this:

*   68710f8 (HEAD, master) Merge branch 'master' of PC:~/projects/_cmake
|\
| * 609b82b (origin/master, origin/HEAD) Changed to work with MathGL version 2. Broken version 1 compatibility!
| * ccc5b8a skeleton changed to introduce project stacks
* | ce19df4 Changed to work with MathGL version 2. Broken version 1 compatibility!
|/
* 35d2eaa (origin/pushee) added eigen3 find module
* 39f4937 small bugfixes and slight changes in the reporting of what's going on

While this is a reasonable thing for git merge to do, it's not what you want. Who cares that you first made the commit against 35d2eaa ? You really just want master to point to the same commit as origin/master . You can get there now with:

git checkout master
git stash # If you have any uncommitted changes
git reset --hard origin/master
git stash pop

And then your history will look like this, just the way you want it.

* 609b82b (HEAD, master, origin/master, origin/HEAD) Changed to work with MathGL version 2. Broken version 1 compatibility!
* ccc5b8a skeleton changed to introduce project stacks
* 35d2eaa (origin/pushee) added eigen3 find module
* 39f4937 small bugfixes and slight changes in the reporting of what's going on

Answer 2

That behavior is correct and expected when upstreaming through patches. The commit IDs for the commits you did locally the the ones you pulled in from upstream should differ. It looks a little odd, but is the it reflects history correctly as you should see in the graphed view of your history. The changes have been introduced on each branch and won't be deleted from either one. Merge never changes existing history you just add more to your branch. If you want to avoid having commits "duplicated" you'd have to change to a 'git rebase' based flow instead of merging upstream into your dev branch.

As additional reference, I found this blog article explaining merge vs. rebase which touches the patch problematic as well: http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control/