Moving the git master branch

[Jeff Johnston]

----- Original Message -----
> From: "Corinna Vinschen" <vinschen@redhat.com>
> To: newlib@sourceware.org
> Sent: Thursday, May 28, 2015 7:20:06 AM
> Subject: Re: Moving the git master branch
> 
> On May 28 12:00, Luca Barbato wrote:
> > On 28/05/15 11:47, Corinna Vinschen wrote:
> > > Hi guys,
> > > 
> > > 
> > > a few weeks ago I made a mistake.  I made Cygwin changes on the master
> > > branch which were not ready for prime time and are still pretty much
> > > experimental and may actually *never* make it into the release.
> > > 
> > > Since we needed a bugfix release, I created a branch to take out the
> > > questionable changes.  But rather than keeping the changes on an
> > > experimental branch and cut the release from master, I made a release
> > > branch called "cygwin-2.0".
> > > 
> > > This leads to the unfortunate situation that I have to merge all
> > > changes from "master" into "cygwin-2.0" all the time.
> > > 
> > > So, since the difference between master and cygwin-2.0 is only the
> > > experimental changeset, what I'd *like* to do is to rename "master"
> > > to "cygwin-acl" and "cygwin-2.0" to "master":
> > > 
> > >   git branch -m master cygwin-acl
> > >   git branch -m cygwin-2.0 master
> > >   git push -f origin master
> > >   git push -f origin cygwin-acl
> > > 
> > > The only downside, as far as I can see, is that the two newlib snapshot
> > > tags
> > > 
> > >   newlib-snapshot-20150423
> > >   newlib-snapshot-20150323
> > > 
> > > are then on the "cygwin-acl" branch rather than on master.  I guess this
> > > could be easily rectified as well by dropping the tags and recreating
> > > them on the master branch.  The differences don't affect newlib or
> > > libgloss anyway.
> > > 
> > > 
> > > Would that be ok?  Does anybody think this should be done differently
> > > and, if so, how?
> > 
> > ## Rewrite the history radically
> > 
> > You could `git rebase -i` to amend the trees, warn everybody to use `git
> > pull --rebase` and force push the amended tree. (also your way requires
> > that to avoid some annoying situations)
> 
> This looks complicated.  The list of changes I see in the editor doesn't
> exactly match the changes which would have to be removed from master,
> I'm not comfortable enough with git to be sure this will result in the
> right state, especially since it seems to change the remote immediately.
> 
> > ## Revert commits
> > 
> > `git revert` isn't exactly friendly with bisect later but if you want to
> > avoid problems for those that git pull blindly this would work better.
> 
> Duh.  I was hoping to avoid reverts.
> 
> 
> So, three strategies now.  Which one is the best?  I saw the renaming
> strategy on the net and it seemed to be the one with the least hassle...
> 

I think that reverting the patches is the right way to go.  Renaming branches
is a hack and it plays around with history.  I have no idea what happens with
users who have the master branch already checked out.  I think that no one should
have to do anything but pull in the future and have the offending patches
removed.

You can revert by committing a patch that changes all files in question to the way they
are supposed to be and has a comment that reverting the changes from a previous
patch.

> 
> Corinna
> 
> --
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat
>