0

I have a local git repository and I run the following:

git.exe pull -v --no-rebase --progress "origin" // pull 1
(make a few local commits)
git.exe pull -v --no-rebase --progress "origin" // pull 2
git log --pretty=format:"%h - %an : %s"         // log 1
git rebase -i HEAD~4
(move local commit 1 down 2 positions)
git log --pretty=format:"%h - %an : %s"         // log 2
git.exe pull -v --no-rebase --progress "origin" // pull 3
git log --pretty=format:"%h - %an : %s"         // log 3

After doing this all commits to the remote repository that I retrieved in pull 1 are now duplicated in the log.

Log 1 looks like this:

84e4015 - Me : Local Commit 3
0dbe86a - Me : Local Commit 2
d57ba2a - Me : Merge branch 'master' of remote repository
a86ea35 - Me : Local Commit 1 before reordering
2fc4fe7 - Remote User 2 : Remote Commit 2
b7a8656 - Remote User 1 : Remote Commit 1
8ce80fc - Me : Merge branch 'master' of remote repository

Log 2 looks like this:

cf1ff7b - Me : Local Commit 3
cd14463 - Me : Local Commit 2
b9d44fb - Me : Local Commit 1 after reordering
9777c56 - Remote User 2 : Remote Commit 2
a2d7d8b - Remote User 1 : Remote Commit 1
8ce80fc - Me : Merge branch 'master' of remote repository

And log 3 looks like this:

e8e1a85 - Me : Merge branch 'master' of remote repository
cf1ff7b - Me : Local Commit 3
cd14463 - Me : Local Commit 2
b9d44fb - Me : Local Commit 1 after reordering
9777c56 - Remote User 2 : Remote Commit 2
a2d7d8b - Remote User 1 : Remote Commit 1
2fc4fe7 - Remote User 2 : Remote Commit 2 // duplicate 2
b7a8656 - Remote User 1 : Remote Commit 1 // duplicate 1
8ce80fc - Me : Merge branch 'master' of remote repository

What have I done wrong? How do I prevent? How do I fix?

Note that I've never pushed to the remote repository, only pulled from it and made local commits. Also note that there are a lot of similarly titled threads to this question but all of them are a little different and the answers there don't seem to apply here.

Samuel
  • 8,063
  • 8
  • 45
  • 41
  • possible duplicate of [Git commits are duplicated in the same branch after doing a rebase](http://stackoverflow.com/questions/9264314/git-commits-are-duplicated-in-the-same-branch-after-doing-a-rebase) – Whymarrh Jun 18 '15 at 20:31

2 Answers2

0

It's not you, it's the remote users. It looks like they have rebased commits that you have already based work on, then pushed back to origin. Not very sociable.

The clue is that remote users' commit refs change from log1 to log2 - they rebased and pushed their work. But your work is based on their pre-rebased commits. So your local repo contains those two commits (2fc4fe7, b7a8656) that their rebase has eradicated from their repo and origin (presumably they pushed with a --force). So when you then pull from origin those local commits appear to be reincarnated to ensure your commit history is preserved, and the remote users' rebased commits (9777c56, a2d7d8b) are merged too. Hence the duplicates.

Roger Marlow
  • 349
  • 3
  • 9
  • Thanks Roger. Related question, if I had 3 commits, commit 3 (newest), commit 2 (middle), and commit 1 (oldest). I pushed commit 3. Then I rebased commit 1 so that it was the newest, and then pushed commit 1. Would I cause the same failure for other users? – Samuel Jan 05 '15 at 14:51
  • Actually Roger, it looks like my local rebase gave the remote users' commits a new SHA, 9777c56 and a2d7d8b in log 2. That shouldn't happen should it? And when I pulled it re-created the original SHAs that were first seen in log 1, 2fc4fe7 and b7a8656. Are you sure it's not my fault? If it is my fault, what did I do wrong? – Samuel Jan 05 '15 at 15:07
  • According to your original posting you didn't push to another repo, so nothing that happened in your local repo could have had an effect on the rest of the world. You can mess around with (new) commits that you make locally but as soon as you push back to origin, or you pull new commits from origin, you must not rebase those commits. Good explanation [here](http://git-scm.com/book/en/v2/Git-Branching-Rebasing#The-Perils-of-Rebasing). – Roger Marlow Jan 05 '15 at 21:58
  • Actually looking at this again it doesn't make sense at all. Getting duplicates in the log is generally a sign of a remote user rebasing commits you are dependent on but in this case the remote users commits are changing without a pull. Can you remember exactly what you did in the interactive rebase? The logs don't seem to tally with the actions. For example comparing log1 to the list of actions, how did commits 0d and 84 occur between pull2 to create the merge commit d5 and log1 being generated? – Roger Marlow Jan 06 '15 at 17:50
  • Roger, I posted a follow up question after reading your response. I believe the problem is that I should have used git pull --rebase. See [git: Pushing Single Commits, Reordering with rebase, Duplicate Commits](http://stackoverflow.com/questions/27785582/git-pushing-single-commits-reordering-with-rebase-duplicate-commits) for details. I haven't confirmed the fix yet. – Samuel Jan 07 '15 at 15:20
  • 1
    You can think of `git pull --rebase origin [your-local-branch]` as what you do if others have made commits to origin while you have been working on your local branch, and you want the commit history to look as if you had done your work after theirs. Regardless of the order of commits (the rebase bit) you have to do a merge at some point. And git pull does a merge, because under the covers it is a git fetch then a git merge. So `git pull --rebase` is the merge you need plus it puts your local commits after any remote commits. Don't forget to push back to origin afterwards. – Roger Marlow Jan 07 '15 at 19:58
0

The problem is with git pull. I should have used:

git pull --rebase

This rebases my local commits so that they are on top, i.e. more recent, than the commits in the remote repo. So when I rebase my commits to reorder one, I'm not rebasing commits that have been pushed to the remote repo. By rebasing commits that had been pushed to the remote repo I was copying them and assigning them a new SHA, and when I did the second git pull it re-pulled the original SHAs/commits, hence the duplicates.

See here for more details:

git: Pushing Single Commits, Reordering with rebase, Duplicate Commits

Community
  • 1
  • 1
Samuel
  • 8,063
  • 8
  • 45
  • 41