[Numpy-discussion] Remove current 1.7 branch?

Ralf Gommers ralf.gommers@googlemail....
Thu Jul 19 01:56:00 CDT 2012


On Thu, Jul 12, 2012 at 1:54 PM, Nathaniel Smith <njs@pobox.com> wrote:

> On Thu, Jul 12, 2012 at 12:48 PM, Benjamin Root <ben.root@ou.edu> 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> 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...
>

$ git co 1.7.x
Switched to branch '1.7.x'
Your branch and 'upstream/maintenance/1.7.x' have diverged,
and have 1 and 124 different commit(s) each, respectively.

$ git pull
Auto-merging numpy/core/SConscript
Auto-merging numpy/core/bscript
CONFLICT (content):

Of course I can fix this easily, but why are we having this long thread,
coming to a conclusion and then doing something else?

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20120719/22975457/attachment-0001.html 


More information about the NumPy-Discussion mailing list