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

[Theodore Tso <tytso@mit.edu>]

On Fri, Feb 02, 2007 at 10:40:49PM -0800, Junio C Hamano wrote:
> I do not think this is a good explanation.  For example, if we
> do this:
> 
> (1) I build a series and push it out.
> 
> 	---o---o---o---j
> 
> (2) Alice clones from me, and builds two commits on top of it.
> 
> 	---o---o---o---j---a---a
> 
> (3) I rewind one and build a few, and push them out.
> 
> 	---o---o---o...j
>                     \
>                      h---h---h---h
> 
> (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.
> 
> Maybe I did not want to have 'j' because it was an incomplete
> solution to some problem....

Another scenario might be if 'j' was just a bad idea, and should have
never been committed in the first place.  Now if Alice builds upon it,
and at some later point Alice asks you to pull from her repository,
'j' will appear back in your repository.  So it's better to have a
changeset which simply undoes 'j' rathern than rewind, once you've
pushed out the repository.

The one exception to this is if 'j' contains something which might be
problematic from a copyright point of view, in which case you're
largely screwed if other people such as Alice has already pulled from
you and started basing changes on 'j'.

							- Ted