Why do I have the same commits in two branches with different hashes

Question

I'm a bit puzzled by this...

I have two branches that have the same series of commits in both of them.

The true history is that they were authored by my colleague, committed and pushed to github on branch A. At some stage I merged branch A with my B branch.

What git now appears to show is his commits in branch A, with their hashes, and the same commits in my (diverged) branch, showing me as author, and a different set of hashes, intermingled with the work I was doing on my branch.

This feels like some sort of rebase issue, (we both use GitHubForWindows some of the time which does rebase as part of sync) but I'm not aware of an issue being reported to either of us.

Any ideas on what caused this, or how to get it straight would be appreciated.

Answer 1

You should get some power tool (plain gitk should do just fine) and closely inspect the matching (but differing in hashes) commits — look for differences in the Author, Committer and Date fields. Also compare the hashes of the parent commits because a commit objects also records the hashes of their parent commits and so otherwise identical commits referring to different parent SHA-1 commit names will be different.

Also could you elaborate on how precisely your commits are "intermingled" with those authored by your peer? Do all those commits form a linear history or there are merge points?

The former would indicate that rebasing was used.

With the information available so far I would do this:

1. Stop using "Github for Windows" for no-brainer solutions tend to create situations you're facing right now: when something breaks you have no idea why it broke and how to unbreak.
2. Get "regular" Git for Windows (and may be Git Extensions if you want fancy GUI which does not try to outsmart the user).
3. Save your current feature branch away by forking another branch off it.
4. (Hard-)reset your feature branch to that of your peer.

5. Cherry-pick your changes from oldest to the newest from the branch you saved.

   This might create conflicts (since these commits will be planted onto a different state of code they were originally created).

In the result you will have a branch which has no "spuriously same" commits.

Then both you and your peer should read up on merging and rebasing workflows, adopt one of them and then, when working on feature branches, do either merging and/or rebasing sensibly, understanding why you're doing this and what happens as a result. I would advise you to not blindly rely on a tool to do the Right Thing™.