3

I have the following Git history:

    D-E-A-B-C-A-B-C (feature2)
   /
  *-D-E (feature1)
 /
*-F (develop)

I have no idea how A, B and C ended up on feature2 twice. I have been rebasing feature2 on and off of feature1 using git rebase feature1 and git rebase --onto develop feature1. I've rectified the situation by cherry-picking A, B and C on to a fresh branch off develop, but: how could this have come about? I'm stumped.

Edit

I have no idea what Github is doing here, but now Git is saying:

Your branch and 'origin/feature2-fresh' have diverged,
and have 113 and 100 different commit(s) each, respectively.

So it seems it's Github's fault?

Kara Brightwell
  • 2,529
  • 1
  • 21
  • 29
  • 1
    These can't be the exact same commits in the sense of them having the same contents and the same SHA-1. What do you mean by the same commits? – Fred Foo Jan 07 '13 at 09:55
  • 1
    Same diff, different SHA-1. I have no idea where they came from. ```git log --graph``` seemed to think develop, whereas ```git branch --contains``` just thought they were on feature2. – Kara Brightwell Jan 07 '13 at 10:06
  • The second error message is indicative of two different rebase (one local, one pushed over to GitHub by another collaborator): the SHA1 are different (even if the content might be similar). One of the two side (local or GitHub) will have to reset its content to the other. – VonC Jan 07 '13 at 11:42

2 Answers2

4

Here's what happened:

  • So I rebased feature2 onto feature1.
  • I rebased feature2 back onto develop.
  • I pushed feature2, then realised there was more work to do, so did the rebase dance again (feature1 was needed to run feature2).

Now the SHA-1s of all the commits unique to feature2 are different to the corresponding commits on origin/feature2.
Without realising, I do a pull. Git dutifully merges all the commits again, because they have different SHAs. The moral of the story is:

Don't rebase a pushed branch.

Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
Kara Brightwell
  • 2,529
  • 1
  • 21
  • 29
1

One possibility:
Duplicate commit can be a telltale for git cherry-pick (see "git - what is cherry-pick?" and its duplicate commit issue).

If A and B were cherry-picked at any point after the rebase, they could be added to feature2 even though that branch already contains A and B (with different SHA1).

If A and B were cherry-picked before the rebase, then A and B should not have been repeated (from git rebase man page)

If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • @MattBrennan well, you can cherry-pick a range of commit ;) http://stackoverflow.com/a/1994491/6309 – VonC Jan 07 '13 at 10:31