This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Moving the git master branch
- From: Luca Barbato <lu_zero at gentoo dot org>
- To: newlib at sourceware dot org
- Date: Thu, 28 May 2015 12:00:15 +0200
- Subject: Re: Moving the git master branch
- Authentication-results: sourceware.org; auth=none
- References: <20150528094702 dot GO16927 at calimero dot vinschen dot de>
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)
## 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.
lu