You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by Jordan Zimmerman <jo...@jordanzimmerman.com> on 2017/03/09 17:26:21 UTC
Change master to be CURATOR-3.0?
I've been thinking it might be time to make the CURATOR-3.0 branch master. Thoughts? I'm not sure the best way to do this from a git perspective. If anyone has suggestions I'd appreciate it.
-Jordan
Re: Change master to be CURATOR-3.0?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
doh - oops
> On Mar 9, 2017, at 10:00 AM, Michael Han <ha...@cloudera.com> wrote:
>
> This email is supposed to send to curator dev list instead of ZK dev list I
> guess...
>
> On Thu, Mar 9, 2017 at 9:26 AM, Jordan Zimmerman <jordan@jordanzimmerman.com
>> wrote:
>
>> I've been thinking it might be time to make the CURATOR-3.0 branch master.
>> Thoughts? I'm not sure the best way to do this from a git perspective. If
>> anyone has suggestions I'd appreciate it.
>>
>> -Jordan
>
>
>
>
> --
> Cheers
> Michael.
Re: Change master to be CURATOR-3.0?
Posted by Michael Han <ha...@cloudera.com>.
This email is supposed to send to curator dev list instead of ZK dev list I
guess...
On Thu, Mar 9, 2017 at 9:26 AM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:
> I've been thinking it might be time to make the CURATOR-3.0 branch master.
> Thoughts? I'm not sure the best way to do this from a git perspective. If
> anyone has suggestions I'd appreciate it.
>
> -Jordan
--
Cheers
Michael.
Re: Change master to be CURATOR-3.0?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I see - I saw some posts about doing a "theirs" style merge. But, I wasn't sure how to do it so that CURATOR-3.0 is merged completely. I thought about some kind of rebase too. But, I'm not a git expert.
-JZ
> On May 2, 2017, at 2:53 PM, Scott Blum <dr...@gmail.com> wrote:
>
> Saying "make CURATOR-3.0 be master" is not really how I would put it,
> saying it that way invites misconception.
>
> CURATOR-3.0 and master are just pointers, no different that if I declared
> two local variables X and Y as pointers to an object. I can make X and Y
> point at the same object, but X and Y are still distinct memory locations
> that contain pointers. That's how git branches work. A branch is just a
> label, a pointer.
>
> If we force pushed master, it really would break all the downstream
> remotes, since they could no longer fast-forward from the current master
> position to the new one. By creating a merge, we ensure that fast-forward
> works as you would expect and anyone who updates downstream will see master
> move from the 2.0 stream to the 3.0 stream of commits.
>
> On Tue, May 2, 2017 at 3:42 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
>> wrote:
>
>> BTW
>>
>> https://issues.apache.org/jira/browse/CURATOR-406 <
>> https://issues.apache.org/jira/browse/CURATOR-406>
>>
>> Any change that was made to master should be merged in CURATOR-3.0 - not
>> everyone remembers to do that (yet another reason to fix this).
>>
>> I follow what you wrote. But, I don't see how to make CURATOR-3.0 be
>> master on remotes/forks without a force.
>>
>> -JZ
>>
>>> On May 2, 2017, at 2:40 PM, Scott Blum <dr...@gmail.com> wrote:
>>>
>>> The best way I can think to explain it is this:
>>>
>>> Every time in the past where you've merged master into 3.0, you've
>> created
>>> a merge commit between master and 3.0. You have always then advanced 3.0
>>> to the merge commit.... but you *could* have chosed to also advance
>> master
>>> to the merge commit, since it's a descendant of both branches.
>>>
>>> So what I've done so far is just checkout apache/CURATOR-3.0, merge in
>>> apache/master. I'm pushing the resulting commit right now to a branch
>>> named "would-be-master". Take a look and see if this looks okay to you.
>>>
>>> It looks like this is pulling in two changes that are currently on
>> master,
>>> but not on 3.0:
>>>
>>> - [CURATOR-386] Allow listener to be passed in to PersistentNode
>>> - CURATOR-401: Make InterProcessMutex.isOwnedByCurrentThread public
>>>
>>> I assume those *should* be merged into 3.0?
>>>
>>> On Tue, May 2, 2017 at 3:33 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com
>>>> wrote:
>>>
>>>> Wow - nice. I didn't see that anywhere on SO. Can you point at doc for
>>>> this or describe the steps first?
>>>>
>>>> -Jordan
>>>>
>>>>> On May 2, 2017, at 2:29 PM, Scott Blum <dr...@gmail.com> wrote:
>>>>>
>>>>> Hey guys, this isn't hard. All we have to do is create a merge commit
>>>>> between 3.0 and master, then you can fast-forward master to the merge
>>>>> commit. No push -f required.
>>>>>
>>>>> Would you guys like me to do this now? I can leave a CURATOR-2.0
>> branch
>>>>> where master is now.
>>>>>
>>>>>
>>>>> On Tue, May 2, 2017 at 3:20 PM, Jordan Zimmerman <
>>>> jordan@jordanzimmerman.com
>>>>>> wrote:
>>>>>
>>>>>> FYI this may be the only reasonable thing to do:
>>>>>>
>>>>>> http://stackoverflow.com/a/2862765/2048051 <
>> http://stackoverflow.com/a/
>>>>>> 2862765/2048051>
>>>>>>
>>>>>> git branch -m master master-2.0
>>>>>> git push origin :master
>>>>>> git push origin master-2.0
>>>>>> git checkout CURATOR-3.0
>>>>>> git checkout -b master
>>>>>> git push origin master
>>>>>>
>>>>>> I don't know what this does to old forks though. When I get a chance
>>>> I'll
>>>>>> play around with a dummy Github project.
>>>>>>
>>>>>> -JZ
>>>>>>
>>>>>>> On May 2, 2017, at 2:15 PM, Jordan Zimmerman <
>>>> jordan@jordanzimmerman.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> I'd like to pick this up again...
>>>>>>>
>>>>>>> ZK 3.5 is now at beta and will soon be the release/master version.
>>>> Also,
>>>>>> I notice more and more CURATOR-3.0 only changes. Sooner or later,
>>>>>> CURATOR-3.0 needs to become master.
>>>>>>>
>>>>>>> Whenever we do it, though, there's the problem of _how_ to do. I've
>>>> been
>>>>>> searching and there doesn't seem to be a clean way to do it. Most of
>> the
>>>>>> solutions I've seen involve doing a "git push -f" eventually which is
>>>> pure
>>>>>> evil as I understand it. Anyone know the best way to do it?
>>>>>>>
>>>>>>> What we have now:
>>>>>>>
>>>>>>> * master (represents the Curator 2.x line)
>>>>>>> * CURATOR-3.0 (represents the Curator 3.x line)
>>>>>>>
>>>>>>> What we should have:
>>>>>>>
>>>>>>> * master-2.0 (what was master)
>>>>>>> * master (represents the Curator 3.x line)
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>> -JZ
>>>>>>>
>>>>>>>> On Mar 10, 2017, at 10:41 AM, Jordan Zimmerman <
>>>>>> jordan@jordanzimmerman.com> wrote:
>>>>>>>>
>>>>>>>> Eventually, it will be the main branch when ZooKeeper 3.5 finally
>>>> exits
>>>>>> alpha/beta. So, I thought that we should reflect that in our repo.
>> Also,
>>>>>> we're starting to get changes that only apply to CURATOR-3.0 branch.
>>>> But,
>>>>>> then, it might screw up our current merge strategy so it could be a
>> bad
>>>>>> idea.
>>>>>>>>
>>>>>>>> -Jordan
>>>>>>>>
>>>>>>>>> On Mar 9, 2017, at 5:14 PM, Cameron McKenzie <
>> mckenzie.cam@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> What's the motivation? Is it just that fixes are more likely to be
>>>> 3.X
>>>>>>>>> centric now, and it's more logical to create PRs to master?
>>>>>>>>>
>>>>>>>>> On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
>>>>>>>>> jordan@jordanzimmerman.com> wrote:
>>>>>>>>>
>>>>>>>>>> I've been thinking it might be time to make the CURATOR-3.0 branch
>>>>>> master.
>>>>>>>>>> Thoughts? I'm not sure the best way to do this from a git
>>>>>> perspective. If
>>>>>>>>>> anyone has suggestions I'd appreciate it.
>>>>>>>>>>
>>>>>>>>>> -Jordan
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: Change master to be CURATOR-3.0?
Posted by Scott Blum <dr...@gmail.com>.
Saying "make CURATOR-3.0 be master" is not really how I would put it,
saying it that way invites misconception.
CURATOR-3.0 and master are just pointers, no different that if I declared
two local variables X and Y as pointers to an object. I can make X and Y
point at the same object, but X and Y are still distinct memory locations
that contain pointers. That's how git branches work. A branch is just a
label, a pointer.
If we force pushed master, it really would break all the downstream
remotes, since they could no longer fast-forward from the current master
position to the new one. By creating a merge, we ensure that fast-forward
works as you would expect and anyone who updates downstream will see master
move from the 2.0 stream to the 3.0 stream of commits.
On Tue, May 2, 2017 at 3:42 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:
> BTW
>
> https://issues.apache.org/jira/browse/CURATOR-406 <
> https://issues.apache.org/jira/browse/CURATOR-406>
>
> Any change that was made to master should be merged in CURATOR-3.0 - not
> everyone remembers to do that (yet another reason to fix this).
>
> I follow what you wrote. But, I don't see how to make CURATOR-3.0 be
> master on remotes/forks without a force.
>
> -JZ
>
> > On May 2, 2017, at 2:40 PM, Scott Blum <dr...@gmail.com> wrote:
> >
> > The best way I can think to explain it is this:
> >
> > Every time in the past where you've merged master into 3.0, you've
> created
> > a merge commit between master and 3.0. You have always then advanced 3.0
> > to the merge commit.... but you *could* have chosed to also advance
> master
> > to the merge commit, since it's a descendant of both branches.
> >
> > So what I've done so far is just checkout apache/CURATOR-3.0, merge in
> > apache/master. I'm pushing the resulting commit right now to a branch
> > named "would-be-master". Take a look and see if this looks okay to you.
> >
> > It looks like this is pulling in two changes that are currently on
> master,
> > but not on 3.0:
> >
> > - [CURATOR-386] Allow listener to be passed in to PersistentNode
> > - CURATOR-401: Make InterProcessMutex.isOwnedByCurrentThread public
> >
> > I assume those *should* be merged into 3.0?
> >
> > On Tue, May 2, 2017 at 3:33 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com
> >> wrote:
> >
> >> Wow - nice. I didn't see that anywhere on SO. Can you point at doc for
> >> this or describe the steps first?
> >>
> >> -Jordan
> >>
> >>> On May 2, 2017, at 2:29 PM, Scott Blum <dr...@gmail.com> wrote:
> >>>
> >>> Hey guys, this isn't hard. All we have to do is create a merge commit
> >>> between 3.0 and master, then you can fast-forward master to the merge
> >>> commit. No push -f required.
> >>>
> >>> Would you guys like me to do this now? I can leave a CURATOR-2.0
> branch
> >>> where master is now.
> >>>
> >>>
> >>> On Tue, May 2, 2017 at 3:20 PM, Jordan Zimmerman <
> >> jordan@jordanzimmerman.com
> >>>> wrote:
> >>>
> >>>> FYI this may be the only reasonable thing to do:
> >>>>
> >>>> http://stackoverflow.com/a/2862765/2048051 <
> http://stackoverflow.com/a/
> >>>> 2862765/2048051>
> >>>>
> >>>> git branch -m master master-2.0
> >>>> git push origin :master
> >>>> git push origin master-2.0
> >>>> git checkout CURATOR-3.0
> >>>> git checkout -b master
> >>>> git push origin master
> >>>>
> >>>> I don't know what this does to old forks though. When I get a chance
> >> I'll
> >>>> play around with a dummy Github project.
> >>>>
> >>>> -JZ
> >>>>
> >>>>> On May 2, 2017, at 2:15 PM, Jordan Zimmerman <
> >> jordan@jordanzimmerman.com>
> >>>> wrote:
> >>>>>
> >>>>> I'd like to pick this up again...
> >>>>>
> >>>>> ZK 3.5 is now at beta and will soon be the release/master version.
> >> Also,
> >>>> I notice more and more CURATOR-3.0 only changes. Sooner or later,
> >>>> CURATOR-3.0 needs to become master.
> >>>>>
> >>>>> Whenever we do it, though, there's the problem of _how_ to do. I've
> >> been
> >>>> searching and there doesn't seem to be a clean way to do it. Most of
> the
> >>>> solutions I've seen involve doing a "git push -f" eventually which is
> >> pure
> >>>> evil as I understand it. Anyone know the best way to do it?
> >>>>>
> >>>>> What we have now:
> >>>>>
> >>>>> * master (represents the Curator 2.x line)
> >>>>> * CURATOR-3.0 (represents the Curator 3.x line)
> >>>>>
> >>>>> What we should have:
> >>>>>
> >>>>> * master-2.0 (what was master)
> >>>>> * master (represents the Curator 3.x line)
> >>>>>
> >>>>> Thoughts?
> >>>>>
> >>>>> -JZ
> >>>>>
> >>>>>> On Mar 10, 2017, at 10:41 AM, Jordan Zimmerman <
> >>>> jordan@jordanzimmerman.com> wrote:
> >>>>>>
> >>>>>> Eventually, it will be the main branch when ZooKeeper 3.5 finally
> >> exits
> >>>> alpha/beta. So, I thought that we should reflect that in our repo.
> Also,
> >>>> we're starting to get changes that only apply to CURATOR-3.0 branch.
> >> But,
> >>>> then, it might screw up our current merge strategy so it could be a
> bad
> >>>> idea.
> >>>>>>
> >>>>>> -Jordan
> >>>>>>
> >>>>>>> On Mar 9, 2017, at 5:14 PM, Cameron McKenzie <
> mckenzie.cam@gmail.com
> >>>
> >>>> wrote:
> >>>>>>>
> >>>>>>> What's the motivation? Is it just that fixes are more likely to be
> >> 3.X
> >>>>>>> centric now, and it's more logical to create PRs to master?
> >>>>>>>
> >>>>>>> On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
> >>>>>>> jordan@jordanzimmerman.com> wrote:
> >>>>>>>
> >>>>>>>> I've been thinking it might be time to make the CURATOR-3.0 branch
> >>>> master.
> >>>>>>>> Thoughts? I'm not sure the best way to do this from a git
> >>>> perspective. If
> >>>>>>>> anyone has suggestions I'd appreciate it.
> >>>>>>>>
> >>>>>>>> -Jordan
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: Change master to be CURATOR-3.0?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
BTW
https://issues.apache.org/jira/browse/CURATOR-406 <https://issues.apache.org/jira/browse/CURATOR-406>
Any change that was made to master should be merged in CURATOR-3.0 - not everyone remembers to do that (yet another reason to fix this).
I follow what you wrote. But, I don't see how to make CURATOR-3.0 be master on remotes/forks without a force.
-JZ
> On May 2, 2017, at 2:40 PM, Scott Blum <dr...@gmail.com> wrote:
>
> The best way I can think to explain it is this:
>
> Every time in the past where you've merged master into 3.0, you've created
> a merge commit between master and 3.0. You have always then advanced 3.0
> to the merge commit.... but you *could* have chosed to also advance master
> to the merge commit, since it's a descendant of both branches.
>
> So what I've done so far is just checkout apache/CURATOR-3.0, merge in
> apache/master. I'm pushing the resulting commit right now to a branch
> named "would-be-master". Take a look and see if this looks okay to you.
>
> It looks like this is pulling in two changes that are currently on master,
> but not on 3.0:
>
> - [CURATOR-386] Allow listener to be passed in to PersistentNode
> - CURATOR-401: Make InterProcessMutex.isOwnedByCurrentThread public
>
> I assume those *should* be merged into 3.0?
>
> On Tue, May 2, 2017 at 3:33 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
>> wrote:
>
>> Wow - nice. I didn't see that anywhere on SO. Can you point at doc for
>> this or describe the steps first?
>>
>> -Jordan
>>
>>> On May 2, 2017, at 2:29 PM, Scott Blum <dr...@gmail.com> wrote:
>>>
>>> Hey guys, this isn't hard. All we have to do is create a merge commit
>>> between 3.0 and master, then you can fast-forward master to the merge
>>> commit. No push -f required.
>>>
>>> Would you guys like me to do this now? I can leave a CURATOR-2.0 branch
>>> where master is now.
>>>
>>>
>>> On Tue, May 2, 2017 at 3:20 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com
>>>> wrote:
>>>
>>>> FYI this may be the only reasonable thing to do:
>>>>
>>>> http://stackoverflow.com/a/2862765/2048051 <http://stackoverflow.com/a/
>>>> 2862765/2048051>
>>>>
>>>> git branch -m master master-2.0
>>>> git push origin :master
>>>> git push origin master-2.0
>>>> git checkout CURATOR-3.0
>>>> git checkout -b master
>>>> git push origin master
>>>>
>>>> I don't know what this does to old forks though. When I get a chance
>> I'll
>>>> play around with a dummy Github project.
>>>>
>>>> -JZ
>>>>
>>>>> On May 2, 2017, at 2:15 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com>
>>>> wrote:
>>>>>
>>>>> I'd like to pick this up again...
>>>>>
>>>>> ZK 3.5 is now at beta and will soon be the release/master version.
>> Also,
>>>> I notice more and more CURATOR-3.0 only changes. Sooner or later,
>>>> CURATOR-3.0 needs to become master.
>>>>>
>>>>> Whenever we do it, though, there's the problem of _how_ to do. I've
>> been
>>>> searching and there doesn't seem to be a clean way to do it. Most of the
>>>> solutions I've seen involve doing a "git push -f" eventually which is
>> pure
>>>> evil as I understand it. Anyone know the best way to do it?
>>>>>
>>>>> What we have now:
>>>>>
>>>>> * master (represents the Curator 2.x line)
>>>>> * CURATOR-3.0 (represents the Curator 3.x line)
>>>>>
>>>>> What we should have:
>>>>>
>>>>> * master-2.0 (what was master)
>>>>> * master (represents the Curator 3.x line)
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> -JZ
>>>>>
>>>>>> On Mar 10, 2017, at 10:41 AM, Jordan Zimmerman <
>>>> jordan@jordanzimmerman.com> wrote:
>>>>>>
>>>>>> Eventually, it will be the main branch when ZooKeeper 3.5 finally
>> exits
>>>> alpha/beta. So, I thought that we should reflect that in our repo. Also,
>>>> we're starting to get changes that only apply to CURATOR-3.0 branch.
>> But,
>>>> then, it might screw up our current merge strategy so it could be a bad
>>>> idea.
>>>>>>
>>>>>> -Jordan
>>>>>>
>>>>>>> On Mar 9, 2017, at 5:14 PM, Cameron McKenzie <mckenzie.cam@gmail.com
>>>
>>>> wrote:
>>>>>>>
>>>>>>> What's the motivation? Is it just that fixes are more likely to be
>> 3.X
>>>>>>> centric now, and it's more logical to create PRs to master?
>>>>>>>
>>>>>>> On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
>>>>>>> jordan@jordanzimmerman.com> wrote:
>>>>>>>
>>>>>>>> I've been thinking it might be time to make the CURATOR-3.0 branch
>>>> master.
>>>>>>>> Thoughts? I'm not sure the best way to do this from a git
>>>> perspective. If
>>>>>>>> anyone has suggestions I'd appreciate it.
>>>>>>>>
>>>>>>>> -Jordan
>>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: Change master to be CURATOR-3.0?
Posted by Scott Blum <dr...@gmail.com>.
The best way I can think to explain it is this:
Every time in the past where you've merged master into 3.0, you've created
a merge commit between master and 3.0. You have always then advanced 3.0
to the merge commit.... but you *could* have chosed to also advance master
to the merge commit, since it's a descendant of both branches.
So what I've done so far is just checkout apache/CURATOR-3.0, merge in
apache/master. I'm pushing the resulting commit right now to a branch
named "would-be-master". Take a look and see if this looks okay to you.
It looks like this is pulling in two changes that are currently on master,
but not on 3.0:
- [CURATOR-386] Allow listener to be passed in to PersistentNode
- CURATOR-401: Make InterProcessMutex.isOwnedByCurrentThread public
I assume those *should* be merged into 3.0?
On Tue, May 2, 2017 at 3:33 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:
> Wow - nice. I didn't see that anywhere on SO. Can you point at doc for
> this or describe the steps first?
>
> -Jordan
>
> > On May 2, 2017, at 2:29 PM, Scott Blum <dr...@gmail.com> wrote:
> >
> > Hey guys, this isn't hard. All we have to do is create a merge commit
> > between 3.0 and master, then you can fast-forward master to the merge
> > commit. No push -f required.
> >
> > Would you guys like me to do this now? I can leave a CURATOR-2.0 branch
> > where master is now.
> >
> >
> > On Tue, May 2, 2017 at 3:20 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com
> >> wrote:
> >
> >> FYI this may be the only reasonable thing to do:
> >>
> >> http://stackoverflow.com/a/2862765/2048051 <http://stackoverflow.com/a/
> >> 2862765/2048051>
> >>
> >> git branch -m master master-2.0
> >> git push origin :master
> >> git push origin master-2.0
> >> git checkout CURATOR-3.0
> >> git checkout -b master
> >> git push origin master
> >>
> >> I don't know what this does to old forks though. When I get a chance
> I'll
> >> play around with a dummy Github project.
> >>
> >> -JZ
> >>
> >>> On May 2, 2017, at 2:15 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com>
> >> wrote:
> >>>
> >>> I'd like to pick this up again...
> >>>
> >>> ZK 3.5 is now at beta and will soon be the release/master version.
> Also,
> >> I notice more and more CURATOR-3.0 only changes. Sooner or later,
> >> CURATOR-3.0 needs to become master.
> >>>
> >>> Whenever we do it, though, there's the problem of _how_ to do. I've
> been
> >> searching and there doesn't seem to be a clean way to do it. Most of the
> >> solutions I've seen involve doing a "git push -f" eventually which is
> pure
> >> evil as I understand it. Anyone know the best way to do it?
> >>>
> >>> What we have now:
> >>>
> >>> * master (represents the Curator 2.x line)
> >>> * CURATOR-3.0 (represents the Curator 3.x line)
> >>>
> >>> What we should have:
> >>>
> >>> * master-2.0 (what was master)
> >>> * master (represents the Curator 3.x line)
> >>>
> >>> Thoughts?
> >>>
> >>> -JZ
> >>>
> >>>> On Mar 10, 2017, at 10:41 AM, Jordan Zimmerman <
> >> jordan@jordanzimmerman.com> wrote:
> >>>>
> >>>> Eventually, it will be the main branch when ZooKeeper 3.5 finally
> exits
> >> alpha/beta. So, I thought that we should reflect that in our repo. Also,
> >> we're starting to get changes that only apply to CURATOR-3.0 branch.
> But,
> >> then, it might screw up our current merge strategy so it could be a bad
> >> idea.
> >>>>
> >>>> -Jordan
> >>>>
> >>>>> On Mar 9, 2017, at 5:14 PM, Cameron McKenzie <mckenzie.cam@gmail.com
> >
> >> wrote:
> >>>>>
> >>>>> What's the motivation? Is it just that fixes are more likely to be
> 3.X
> >>>>> centric now, and it's more logical to create PRs to master?
> >>>>>
> >>>>> On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
> >>>>> jordan@jordanzimmerman.com> wrote:
> >>>>>
> >>>>>> I've been thinking it might be time to make the CURATOR-3.0 branch
> >> master.
> >>>>>> Thoughts? I'm not sure the best way to do this from a git
> >> perspective. If
> >>>>>> anyone has suggestions I'd appreciate it.
> >>>>>>
> >>>>>> -Jordan
> >>>>
> >>>
> >>
> >>
>
>
Re: Change master to be CURATOR-3.0?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Wow - nice. I didn't see that anywhere on SO. Can you point at doc for this or describe the steps first?
-Jordan
> On May 2, 2017, at 2:29 PM, Scott Blum <dr...@gmail.com> wrote:
>
> Hey guys, this isn't hard. All we have to do is create a merge commit
> between 3.0 and master, then you can fast-forward master to the merge
> commit. No push -f required.
>
> Would you guys like me to do this now? I can leave a CURATOR-2.0 branch
> where master is now.
>
>
> On Tue, May 2, 2017 at 3:20 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
>> wrote:
>
>> FYI this may be the only reasonable thing to do:
>>
>> http://stackoverflow.com/a/2862765/2048051 <http://stackoverflow.com/a/
>> 2862765/2048051>
>>
>> git branch -m master master-2.0
>> git push origin :master
>> git push origin master-2.0
>> git checkout CURATOR-3.0
>> git checkout -b master
>> git push origin master
>>
>> I don't know what this does to old forks though. When I get a chance I'll
>> play around with a dummy Github project.
>>
>> -JZ
>>
>>> On May 2, 2017, at 2:15 PM, Jordan Zimmerman <jo...@jordanzimmerman.com>
>> wrote:
>>>
>>> I'd like to pick this up again...
>>>
>>> ZK 3.5 is now at beta and will soon be the release/master version. Also,
>> I notice more and more CURATOR-3.0 only changes. Sooner or later,
>> CURATOR-3.0 needs to become master.
>>>
>>> Whenever we do it, though, there's the problem of _how_ to do. I've been
>> searching and there doesn't seem to be a clean way to do it. Most of the
>> solutions I've seen involve doing a "git push -f" eventually which is pure
>> evil as I understand it. Anyone know the best way to do it?
>>>
>>> What we have now:
>>>
>>> * master (represents the Curator 2.x line)
>>> * CURATOR-3.0 (represents the Curator 3.x line)
>>>
>>> What we should have:
>>>
>>> * master-2.0 (what was master)
>>> * master (represents the Curator 3.x line)
>>>
>>> Thoughts?
>>>
>>> -JZ
>>>
>>>> On Mar 10, 2017, at 10:41 AM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>>>
>>>> Eventually, it will be the main branch when ZooKeeper 3.5 finally exits
>> alpha/beta. So, I thought that we should reflect that in our repo. Also,
>> we're starting to get changes that only apply to CURATOR-3.0 branch. But,
>> then, it might screw up our current merge strategy so it could be a bad
>> idea.
>>>>
>>>> -Jordan
>>>>
>>>>> On Mar 9, 2017, at 5:14 PM, Cameron McKenzie <mc...@gmail.com>
>> wrote:
>>>>>
>>>>> What's the motivation? Is it just that fixes are more likely to be 3.X
>>>>> centric now, and it's more logical to create PRs to master?
>>>>>
>>>>> On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
>>>>> jordan@jordanzimmerman.com> wrote:
>>>>>
>>>>>> I've been thinking it might be time to make the CURATOR-3.0 branch
>> master.
>>>>>> Thoughts? I'm not sure the best way to do this from a git
>> perspective. If
>>>>>> anyone has suggestions I'd appreciate it.
>>>>>>
>>>>>> -Jordan
>>>>
>>>
>>
>>
Re: Change master to be CURATOR-3.0?
Posted by Scott Blum <dr...@gmail.com>.
Hey guys, this isn't hard. All we have to do is create a merge commit
between 3.0 and master, then you can fast-forward master to the merge
commit. No push -f required.
Would you guys like me to do this now? I can leave a CURATOR-2.0 branch
where master is now.
On Tue, May 2, 2017 at 3:20 PM, Jordan Zimmerman <jordan@jordanzimmerman.com
> wrote:
> FYI this may be the only reasonable thing to do:
>
> http://stackoverflow.com/a/2862765/2048051 <http://stackoverflow.com/a/
> 2862765/2048051>
>
> git branch -m master master-2.0
> git push origin :master
> git push origin master-2.0
> git checkout CURATOR-3.0
> git checkout -b master
> git push origin master
>
> I don't know what this does to old forks though. When I get a chance I'll
> play around with a dummy Github project.
>
> -JZ
>
> > On May 2, 2017, at 2:15 PM, Jordan Zimmerman <jo...@jordanzimmerman.com>
> wrote:
> >
> > I'd like to pick this up again...
> >
> > ZK 3.5 is now at beta and will soon be the release/master version. Also,
> I notice more and more CURATOR-3.0 only changes. Sooner or later,
> CURATOR-3.0 needs to become master.
> >
> > Whenever we do it, though, there's the problem of _how_ to do. I've been
> searching and there doesn't seem to be a clean way to do it. Most of the
> solutions I've seen involve doing a "git push -f" eventually which is pure
> evil as I understand it. Anyone know the best way to do it?
> >
> > What we have now:
> >
> > * master (represents the Curator 2.x line)
> > * CURATOR-3.0 (represents the Curator 3.x line)
> >
> > What we should have:
> >
> > * master-2.0 (what was master)
> > * master (represents the Curator 3.x line)
> >
> > Thoughts?
> >
> > -JZ
> >
> >> On Mar 10, 2017, at 10:41 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
> >>
> >> Eventually, it will be the main branch when ZooKeeper 3.5 finally exits
> alpha/beta. So, I thought that we should reflect that in our repo. Also,
> we're starting to get changes that only apply to CURATOR-3.0 branch. But,
> then, it might screw up our current merge strategy so it could be a bad
> idea.
> >>
> >> -Jordan
> >>
> >>> On Mar 9, 2017, at 5:14 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
> >>>
> >>> What's the motivation? Is it just that fixes are more likely to be 3.X
> >>> centric now, and it's more logical to create PRs to master?
> >>>
> >>> On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
> >>> jordan@jordanzimmerman.com> wrote:
> >>>
> >>>> I've been thinking it might be time to make the CURATOR-3.0 branch
> master.
> >>>> Thoughts? I'm not sure the best way to do this from a git
> perspective. If
> >>>> anyone has suggestions I'd appreciate it.
> >>>>
> >>>> -Jordan
> >>
> >
>
>
Re: Change master to be CURATOR-3.0?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
FYI this may be the only reasonable thing to do:
http://stackoverflow.com/a/2862765/2048051 <http://stackoverflow.com/a/2862765/2048051>
git branch -m master master-2.0
git push origin :master
git push origin master-2.0
git checkout CURATOR-3.0
git checkout -b master
git push origin master
I don't know what this does to old forks though. When I get a chance I'll play around with a dummy Github project.
-JZ
> On May 2, 2017, at 2:15 PM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
>
> I'd like to pick this up again...
>
> ZK 3.5 is now at beta and will soon be the release/master version. Also, I notice more and more CURATOR-3.0 only changes. Sooner or later, CURATOR-3.0 needs to become master.
>
> Whenever we do it, though, there's the problem of _how_ to do. I've been searching and there doesn't seem to be a clean way to do it. Most of the solutions I've seen involve doing a "git push -f" eventually which is pure evil as I understand it. Anyone know the best way to do it?
>
> What we have now:
>
> * master (represents the Curator 2.x line)
> * CURATOR-3.0 (represents the Curator 3.x line)
>
> What we should have:
>
> * master-2.0 (what was master)
> * master (represents the Curator 3.x line)
>
> Thoughts?
>
> -JZ
>
>> On Mar 10, 2017, at 10:41 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
>>
>> Eventually, it will be the main branch when ZooKeeper 3.5 finally exits alpha/beta. So, I thought that we should reflect that in our repo. Also, we're starting to get changes that only apply to CURATOR-3.0 branch. But, then, it might screw up our current merge strategy so it could be a bad idea.
>>
>> -Jordan
>>
>>> On Mar 9, 2017, at 5:14 PM, Cameron McKenzie <mc...@gmail.com> wrote:
>>>
>>> What's the motivation? Is it just that fixes are more likely to be 3.X
>>> centric now, and it's more logical to create PRs to master?
>>>
>>> On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
>>> jordan@jordanzimmerman.com> wrote:
>>>
>>>> I've been thinking it might be time to make the CURATOR-3.0 branch master.
>>>> Thoughts? I'm not sure the best way to do this from a git perspective. If
>>>> anyone has suggestions I'd appreciate it.
>>>>
>>>> -Jordan
>>
>
Re: Change master to be CURATOR-3.0?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I'd like to pick this up again...
ZK 3.5 is now at beta and will soon be the release/master version. Also, I notice more and more CURATOR-3.0 only changes. Sooner or later, CURATOR-3.0 needs to become master.
Whenever we do it, though, there's the problem of _how_ to do. I've been searching and there doesn't seem to be a clean way to do it. Most of the solutions I've seen involve doing a "git push -f" eventually which is pure evil as I understand it. Anyone know the best way to do it?
What we have now:
* master (represents the Curator 2.x line)
* CURATOR-3.0 (represents the Curator 3.x line)
What we should have:
* master-2.0 (what was master)
* master (represents the Curator 3.x line)
Thoughts?
-JZ
> On Mar 10, 2017, at 10:41 AM, Jordan Zimmerman <jo...@jordanzimmerman.com> wrote:
>
> Eventually, it will be the main branch when ZooKeeper 3.5 finally exits alpha/beta. So, I thought that we should reflect that in our repo. Also, we're starting to get changes that only apply to CURATOR-3.0 branch. But, then, it might screw up our current merge strategy so it could be a bad idea.
>
> -Jordan
>
>> On Mar 9, 2017, at 5:14 PM, Cameron McKenzie <mc...@gmail.com> wrote:
>>
>> What's the motivation? Is it just that fixes are more likely to be 3.X
>> centric now, and it's more logical to create PRs to master?
>>
>> On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>>> I've been thinking it might be time to make the CURATOR-3.0 branch master.
>>> Thoughts? I'm not sure the best way to do this from a git perspective. If
>>> anyone has suggestions I'd appreciate it.
>>>
>>> -Jordan
>
Re: Change master to be CURATOR-3.0?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Eventually, it will be the main branch when ZooKeeper 3.5 finally exits alpha/beta. So, I thought that we should reflect that in our repo. Also, we're starting to get changes that only apply to CURATOR-3.0 branch. But, then, it might screw up our current merge strategy so it could be a bad idea.
-Jordan
> On Mar 9, 2017, at 5:14 PM, Cameron McKenzie <mc...@gmail.com> wrote:
>
> What's the motivation? Is it just that fixes are more likely to be 3.X
> centric now, and it's more logical to create PRs to master?
>
> On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> I've been thinking it might be time to make the CURATOR-3.0 branch master.
>> Thoughts? I'm not sure the best way to do this from a git perspective. If
>> anyone has suggestions I'd appreciate it.
>>
>> -Jordan
Re: Change master to be CURATOR-3.0?
Posted by Cameron McKenzie <mc...@gmail.com>.
What's the motivation? Is it just that fixes are more likely to be 3.X
centric now, and it's more logical to create PRs to master?
On Fri, Mar 10, 2017 at 4:26 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> I've been thinking it might be time to make the CURATOR-3.0 branch master.
> Thoughts? I'm not sure the best way to do this from a git perspective. If
> anyone has suggestions I'd appreciate it.
>
> -Jordan