Re: Moving the git master branch

[Jeff Johnston <jjohnstn at redhat dot com>]

----- Corinna Vinschen <vinschen@redhat.com> wrote:
> On May 28 13:07, Jeff Johnston wrote:
> > > From: "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
> > > > > [...]
> > > > ## 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.
> 
> In the meantime, Yaakov and I were playing around with git merge
> along the lines of what's described in
> 
>   https://stackoverflow.com/questions/2763006/change-the-current-branch-to-master-in-git
> 
> The first answer.  This results in an unbroken history in master, which
> contains both, the master history as well as the cygwin-2.0 branch
> history.  Afterwards, I'll just have to cut my new experimental
> "cygwin-acl" branch from master HEAD and apply my patches to that branch
> again.
> 
> Is that ok, Jeff?
> 

Yes.  It seems to be the recommended way to do what you want to do and doesn't screw up
the history.

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