On Thursday, July 12, 2012, Nathaniel Smith wrote: > On Thu, Jul 12, 2012 at 12:48 PM, Benjamin Root > <ben.r...@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.har...@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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
