On Thursday, July 12, 2012, Nathaniel Smith wrote:
> On Thu, Jul 12, 2012 at 12:48 PM, Benjamin Root <ben.root@ou.edu<javascript:;>>
> wrote:
> >
> >
> > On Thursday, July 12, 2012, Thouis (Ray) Jones wrote:
> >>
> >> On Thu, Jul 12, 2012 at 1:28 AM, Charles R Harris
> >> <charlesr.harris@gmail.com <javascript:;>> wrote:
> >> > Hi All,
> >> >
> >> > Travis and I agree that it would be appropriate to remove the current
> >> > 1.7.x
> >> > branch and branch again after a code freeze. That way we can avoid the
> >> > pain
> >> > and potential errors of backports. It is considered bad form to mess
> >> > with
> >> > public repositories that way, so another option would be to rename the
> >> > branch, although I'm not sure how well that would work. Suggestions?
> >>
> >> I might be mistaken, but if the branch is merged into master (even if
> >> that merge makes no changes), I think it's safe to delete it at that
> >> point (and recreate it at a later date with the same name) with
> >> regards to remote repositories. It should be fairly easy to test.
> >>
> >> Ray Jones
> >
> >
> > No, that is not the case. We had a situation occur awhile back where
> one of
> > the public branches of mpl got completely messed up. You can't even
> rename
> > it since the rename doesn't occur in the pulls and merges.
> >
> > What we ended up doing was creating a brand new branch "v1.0.x-maint" and
> > making sure all the devs knew to switch over to that. You might even go
> a
> > step further and make a final commit to the bad branch that makes the
> build
> > fail with a big note explaining what to do.
>> The branch isn't bad, it's just out of date. So long as the new
> version of the branch has the current version of the branch in its
> ancestry, then everything will be fine.
>> Option 1:
> git checkout master
> git merge maint1.7.x
> git checkout maint1.7.x
> git merge master # will be a fast-forward
>> Option 2:
> git checkout master
> git merge maint1.7.x
> git branch -d maint1.7.x # delete the branch
> git checkout -b maint1.7.x # recreate it
>> In git terms these two options are literally identical; they result in
> the exact same repo state...
>> -N
Ah, I misunderstood. Then yes, I think this is correct.
Ben Root
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120712/31785d17/attachment-0001.html