[Numpy-discussion] Remove current 1.7 branch?

[Ondřej Čertík]

On Thu, Jul 19, 2012 at 8:56 AM, Ralf Gommers
<ralf.gommers at googlemail.com> 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?

Unfortunately the maintenance/1.7.x was rebased, but when I pulled
the new branch into my local repository, I have carefully checked
and I think that no work/patches were lost.

As to me, one should try not to do any rebasing once the branch is
up there, visible to everybody. But apart from that, for example
in SymPy I think we always try to merge the release branch (after the release)
with the master, and remove it. The tag stays there, so if (in the future)
one has to add some new patches and create a bug-fix release, one can easily
do so. At the same time, one doesn't have to carry all these branches around.

Ondrej