Andy Parkins <andyparkins@xxxxxxxxx> writes: > In the following I've assumed that both "h" and "a" commits are > independent work, neither of which works on "j" (which isn't quite what > you described). It's not really appropriate for the tutorial, so I > haven't really helped you. > ... >> (4) Alice pulls from me again: >> >> ---o---o---o---j---a---a---* >> \ / >> h---h---h---h >> >> Contrary to the description, git will happily have Alice merge >> between the two branches, and never gets confused. > > The problem is not that the working tree is wrong, it is that the > history is wrong. This sequence of development isn't best represented > by a merge. When we look at the history later, we'll see it as two > branches, but that isn't true. > > The graph shows that "j" was committed and then probably conflicted > in "*" and fixed. The problem is that you can't point to any non-merge > commit that reverted/corrected "j" and explains why that wasn't a good > idea - so the "story" that the history tells us is incomplete. The > correction was done just as a conflict resolution in "*". Actually, if you are assuming a, h, and j are unrelated, then the merge done by Alice will _not_ revert 'j', so the history will perfectly be fine. The merge result will have a half-baked work done with 'j', and everybody can build on top of. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html