[Numpy-discussion] Remove current 1.7 branch?

[Travis Oliphant]

I'm not sure what the conclusion actually was from this long thread. 

But, in trying to update the 1.7.x branch, I ended up in a very odd state with respect to the github pages.   I used git filter-branch to try and get rid of "empty" commits that were showing up for some reason.   However, this resulted in a branch that seemed fine on my local version but when pushed to github ended up duplicating nearly every commit in the maintenance branch so that the commits page for maintenance/1.7.x showed a duplicate commit for every actual commit, 

I didn't know how to fix this except to delete the branch (after doing a diff with master), recreate the branch, and apply the saved diff as a patch.   I'm very sorry if I messed anyone up.    

I thought the plan was to delete the branch anyway.     There could be something else wrong as well, but I'm not sure what the implication of your message is, exactly. 

People using the maintenance/1.7.x branch (how many people were actually using it?) will need to delete their local branch and re-pull from github.

Best, 

-Travis
 



On Jul 19, 2012, at 1:56 AM, Ralf Gommers wrote:

> 
> 
> On Thu, Jul 12, 2012 at 1:54 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Thu, Jul 12, 2012 at 12:48 PM, Benjamin Root <ben.root at 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 at 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
> 
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20120719/af1a48c2/attachment.html>