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.
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
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:
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™.