Moving the git master branch

[Corinna Vinschen]

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?


Thanks,
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/725f9f0e/attachment.sig>