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

[Andy Parkins <andyparkins@gmail.com>]

On Saturday 2007, February 03 06:40, Junio C Hamano wrote:

>     Also, don't use "git reset" on a publicly-visible branch that
>     other developers pull from, as git will be confused by history
>     that disappears in this way.
>
> I do not think this is a good explanation.  For example, if we
> do this:

I agree it's not a good explanation, I think it is good policy though.  
I love an oppourtunity to blather on and your post has given it to 
me :-)  I'm sure I'll be preaching to the converted though.

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.

-----------------
git's easy manipulation of branches encourages one to try to make 
history really tell the story of development.  It's more than just 
recording snapshots, there is information in the history itself - 
reasons for decisions can be recorded - separating and collecting 
commits into appropriate branches instead of one giant linear block.

As you say git is perfectly okay with the rewound branch and will do the 
Right Thing to preserve the changes.  However, it won't get the spirit 
of the changes right.

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

Any of these would be correct:

1) "h" and "a" are parallel; "j" never happens

 ---o---o---o----a-----a----*
             \             /
              h---h---h---h

2) Alice corrects "j" with a "!j" revision - "!j" would then describe 
why "j" was wrong and what the fix was.  "h" would have to have nothing 
to do with the "j" topic in this case.

 ---o---o---o---j---!j---a---a---*
             \                  /
              h-----h-----h----h

Of course, both of these require information from the developer. (1) 
can't be done after the push has been done (because "j" is already "out 
there") and (2) requires that "h" know that Alice has fixed the problem 
and the Alice knows that the "j" problem needs fixing (and probably 
doesn't belong in Alice's branch anyway).

The only solution that keeps the history integrity, is the one that all 
the git manuals reccommend.

3) Don't rebase at all, correct the problem and record the correction.

  --o---o---o---j------a------a------*
                 \                  /
                  !j---h---h---h---h

That is - once a mistaken commit has been pushed out, it's there 
forever, accept that and don't rebase to before the last push.  
Sometimes it makes the history less pretty, but it makes it more right.  
Without "!j", no one would ever know what was wrong with "j".

In short - heed the warnings - you will get much better history if you 
don't rebase branches that have already been pushed upstream.
-----------------------

How about that as the explanation for the tutorial?  What do you mean I 
haven't simplified anything and have replaced one paragraph with a page 
worth of overly wordy ravings?  HOW DARE YOU!  :-)



Andy
-- 
Dr Andrew Parkins, M Eng (Hons), AMIEE
andyparkins@gmail.com