Moving the git master branch

[Corinna Vinschen]

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


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20150528/11fba2c1/attachment.sig>