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 <[email protected] > 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 <[email protected]> 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 < > [email protected] > >> 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 <[email protected]> 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 < > >> [email protected] > >>>> 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 < > >> [email protected]> > >>>> 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 < > >>>> [email protected]> 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 < > [email protected] > >>> > >>>> 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 < > >>>>>>> [email protected]> 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 > >>>>>> > >>>>> > >>>> > >>>> > >> > >> > >
