Re: Why is it bad to rewind a branch that has already been pushed out?

> 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 "*".