I'm trying to help a coworker figure out what a bunch of "empty commit" warnings were about in his recent merge. I opened up gitk, and saw something like this:
_o (Z) Merge branch 'new-branch' (yesterday)
o | (Y) Fix bad merge (person 1)
o_| (X) Merge branch 'master' into new-branch (recent)
o | (W) Last legitimate commit that belongs on new-branch (person 1)
| | ... work on master ...
o | (F) Legitimate commit that actually belongs on new-branch (person 2)
| | ... work on master ...
o | (E) Legitimate commit that should have been on master (person 2)
o | (D') Even more work etc... (committed by person 2)
o | (C') More work in master (committed by person 2)
o | (A') Normal work in master (committed by person 2)
| o (D) Even more work etc... (authored by random person)
| o (C) More work in master (authored by random person)
o | (B) Starting to work on new-branch (person 1)
|_o (A) Normal work in master (authored by random person)
o Common Ancestor (weeks ago)
So obviously the two people working on this branch should have merged from master into their branch more often, and then these piles of merge warnings would have been more obvious. The team member whose name was in the committer field of the duplicated commits says he probably did a pull --rebase to cause them, but I can't wrap my head around how that could work. Can anyone explain what might have happened?
I'm not looking for a way to fix the merge warnings, since they seemed benign. I just want to understand what happened so I can prevent it from happening in the future. My team is relatively new to git, so I'm trying to help them understand it one small step at a time, using trial and error for the most part.
Thanks!

