You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by Jordan Zimmerman <jo...@jordanzimmerman.com> on 2015/08/24 07:25:27 UTC
CURATOR-217?
Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
-Jordan
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
I have raised CURATOR-254 for this.
On Wed, Aug 26, 2015 at 10:41 AM, Cameron McKenzie <mc...@gmail.com>
wrote:
> I've had a bit of a look at it and the test seems very fragile. It already
> has a bit of built in margin for error, but it relies on the consumers
> being able to consume messages off the queue faster than they are produced.
> If more than 20 messages end up on the queue at any time then test test
> fails.
>
> Anyway, I will raise a JIRA and we can discuss there.
>
> On Wed, Aug 26, 2015 at 9:29 AM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
>> Thanks Mike,
>> On master. I'll have a bit of a look into it and let you know. I think
>> that it's a race condition based on how the test is structured.
>> cheers
>>
>> On Wed, Aug 26, 2015 at 9:18 AM, Mike Drob <ma...@cloudera.com> wrote:
>>
>>> Is this on 3.0 or master? Can you create a JIRA with some log output?
>>>
>>> On Tue, Aug 25, 2015 at 6:15 PM, Cameron McKenzie <
>>> mckenzie.cam@gmail.com>
>>> wrote:
>>>
>>> > Is anyone seeing fairly consistent failure of the
>>> >
>>> > TestBoundedDistributedQueue.testMulti:184
>>> >
>>> > test? When I run from inside eclipse in isolation it seems ok, but
>>> running
>>> > a 'mvn test' seems to fail on this test with some consistency. The
>>> changes
>>> > for CURATOR-167 certainly haven't caused this to happen.
>>> > cheers
>>> >
>>> > On Wed, Aug 26, 2015 at 7:45 AM, Cameron McKenzie <
>>> mckenzie.cam@gmail.com>
>>> > wrote:
>>> >
>>> > > Thanks Scott,
>>> > > I will merge into master.
>>> > > cheers
>>> > >
>>> > > On Wed, Aug 26, 2015 at 1:00 AM, Scott Blum <dr...@gmail.com>
>>> > wrote:
>>> > >
>>> > >> Yep, that looks perfect. Is CURATOR-167 done? If so, we can just
>>> > >> fast-foward merge it into master now.
>>> > >>
>>> > >> On Tue, Aug 25, 2015 at 12:11 AM, Cameron McKenzie <
>>> > >> mckenzie.cam@gmail.com>
>>> > >> wrote:
>>> > >>
>>> > >> > Thanks Scott,
>>> > >> > Done, would you mind checking the origin/CURATOR-167 to make sure
>>> > that I
>>> > >> > haven't done anything wrong! I have done a git pull on a different
>>> > >> machine
>>> > >> > and it seems to be ok.
>>> > >> > cheers
>>> > >> >
>>> > >> > On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum <
>>> dragonsinth@gmail.com>
>>> > >> wrote:
>>> > >> >
>>> > >> > > You just force push your branch.
>>> > >> > >
>>> > >> > > If it's your feature branch, and you know you have it in a good
>>> > state
>>> > >> > > locally, you can just force push the remote branch into the same
>>> > >> state.
>>> > >> > >
>>> > >> > > You'd never want to do that to master, a release branch, or
>>> someone
>>> > >> > else's
>>> > >> > > branch.
>>> > >> > > On Aug 24, 2015 11:15 PM, "Cameron McKenzie" <
>>> > mckenzie.cam@gmail.com>
>>> > >> > > wrote:
>>> > >> > >
>>> > >> > > > Thanks Mike,
>>> > >> > > > That was a good description. The CURATOR-167 branch is
>>> definitely
>>> > >> there
>>> > >> > > as
>>> > >> > > > it's been a pull request for the last few months. So, I'll
>>> await
>>> > >> your
>>> > >> > > > thoughts in the morning. Alternatively, I can just merge
>>> master
>>> > >> instead
>>> > >> > > of
>>> > >> > > > rebasing it.
>>> > >> > > >
>>> > >> > > > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <
>>> madrob@cloudera.com>
>>> > >> > wrote:
>>> > >> > > >
>>> > >> > > > > Yea, that's the big downside with rebasing, is that remotes
>>> > don't
>>> > >> > > exactly
>>> > >> > > > > keep up with the history. I'm going to try to explain this
>>> as
>>> > best
>>> > >> > as I
>>> > >> > > > > can, but usually I point people towards this excellent "Git
>>> for
>>> > >> Ages
>>> > >> > 4
>>> > >> > > > and
>>> > >> > > > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he
>>> > talks
>>> > >> > about
>>> > >> > > > > rebases at the very very end, around the 1:30 mark.
>>> > >> > > > >
>>> > >> > > > > Essentially, your current version of the branch does not
>>> have
>>> > the
>>> > >> > > remote
>>> > >> > > > > version of the as an ancestor. Which is correct, when you
>>> did
>>> > the
>>> > >> > > rebase,
>>> > >> > > > > you wrote a new commit lineage.
>>> > >> > > > >
>>> > >> > > > > I didn't realize that there was already a CURATOR-167 branch
>>> > >> pushed
>>> > >> > to
>>> > >> > > > the
>>> > >> > > > > repo when I gave you those steps. I'll have to look at
>>> what's
>>> > >> going
>>> > >> > on
>>> > >> > > > with
>>> > >> > > > > a fresh set of eyes in the morning.
>>> > >> > > > >
>>> > >> > > > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <
>>> > >> > > > mckenzie.cam@gmail.com>
>>> > >> > > > > wrote:
>>> > >> > > > >
>>> > >> > > > > > I just tried this and obviously I'm doing something wrong.
>>> > >> > > > > >
>>> > >> > > > > > git checkout CURATOR-167
>>> > >> > > > > > git pull
>>> > >> > > > > > git rebase -i origin/master
>>> > >> > > > > >
>>> > >> > > > > > #This gives me a dialog with one commit with pick
>>> > >> > > > > > Save and exit
>>> > >> > > > > > #This gives a merge conflict and leaves me in a detached
>>> head
>>> > >> state
>>> > >> > > (I
>>> > >> > > > > > presume this is ok).
>>> > >> > > > > > Fix up the merge conflict
>>> > >> > > > > > git rebase --continue
>>> > >> > > > > > #This gives me a dialog to commit the changes
>>> > >> > > > > > Save and exit
>>> > >> > > > > > #Everything seems fine at this point. Builds ok, tests
>>> run ok.
>>> > >> > > > > >
>>> > >> > > > > > git push
>>> > >> > > > > >
>>> > >> > > > > > ! [rejected] CURATOR-167 -> CURATOR-167
>>> > >> (non-fast-forward)
>>> > >> > > > > > error: failed to push some refs to '
>>> > >> > > > > > https://git-wip-us.apache.org/repos/asf/curator.git'
>>> > >> > > > > > hint: Updates were rejected because the tip of your
>>> current
>>> > >> branch
>>> > >> > is
>>> > >> > > > > > behind
>>> > >> > > > > > hint: its remote counterpart. Integrate the remote changes
>>> > (e.g.
>>> > >> > > > > > hint: 'git pull ...') before pushing again.
>>> > >> > > > > > hint: See the 'Note about fast-forwards' in 'git push
>>> --help'
>>> > >> for
>>> > >> > > > > details.
>>> > >> > > > > >
>>> > >> > > > > > There have been no changes on the branch since I did the
>>> pull
>>> > >> > before
>>> > >> > > > the
>>> > >> > > > > > rebase.
>>> > >> > > > > >
>>> > >> > > > > > Any ideas?
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > >
>>> > >> > > > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <
>>> > >> > > > > mckenzie.cam@gmail.com>
>>> > >> > > > > > wrote:
>>> > >> > > > > >
>>> > >> > > > > > > Thanks Mike,
>>> > >> > > > > > > Will give it a spin today some time.
>>> > >> > > > > > > cheers
>>> > >> > > > > > >
>>> > >> > > > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <
>>> > >> madrob@cloudera.com>
>>> > >> > > > > wrote:
>>> > >> > > > > > >
>>> > >> > > > > > >> if you're going to tray that, here's what you want to
>>> do
>>> > >> > (assuming
>>> > >> > > > > > command
>>> > >> > > > > > >> line)
>>> > >> > > > > > >>
>>> > >> > > > > > >> git checkout CURATOR-167 # start with the branch that
>>> you
>>> > are
>>> > >> > > > changing
>>> > >> > > > > > >> git rebase -i master # rebase the current branch on
>>> top of
>>> > >> the
>>> > >> > > given
>>> > >> > > > > > >> branch
>>> > >> > > > > > >>
>>> > >> > > > > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
>>> > >> > > > > > mckenzie.cam@gmail.com
>>> > >> > > > > > >> >
>>> > >> > > > > > >> wrote:
>>> > >> > > > > > >>
>>> > >> > > > > > >> > Scott,
>>> > >> > > > > > >> > I've been using a similar approach to Jordan given
>>> that's
>>> > >> what
>>> > >> > > I'm
>>> > >> > > > > > used
>>> > >> > > > > > >> to,
>>> > >> > > > > > >> > but I'm happy to try your approach. I'm going to try
>>> and
>>> > >> fix
>>> > >> > up
>>> > >> > > > > > >> CURATOR-167
>>> > >> > > > > > >> > as it will no longer cleanly merge (it's been sitting
>>> > >> there a
>>> > >> > > > > while).
>>> > >> > > > > > >> So, I
>>> > >> > > > > > >> > should rebase master into the CURATOR-167 branch?
>>> > >> > > > > > >> > cheers
>>> > >> > > > > > >> >
>>> > >> > > > > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <
>>> > >> > > > dragonsinth@apache.org
>>> > >> > > > > >
>>> > >> > > > > > >> > wrote:
>>> > >> > > > > > >> >
>>> > >> > > > > > >> > > LOL! So sorry to hear that. Yeah, it's definitely
>>> > >> possible
>>> > >> > > to
>>> > >> > > > > mess
>>> > >> > > > > > >> > > things up badly. If I'm doing something
>>> particularly
>>> > >> risky,
>>> > >> > > > I'll
>>> > >> > > > > > just
>>> > >> > > > > > >> > "git
>>> > >> > > > > > >> > > branch original" before I start, so as to leave a
>>> > branch
>>> > >> > > pointer
>>> > >> > > > > at
>>> > >> > > > > > my
>>> > >> > > > > > >> > > start point as a safe recovery if it goes south. I
>>> > also
>>> > >> use
>>> > >> > > > gitk
>>> > >> > > > > to
>>> > >> > > > > > >> > > visualize sometimes.
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> > > Another major selling point for rebase (-i) is that
>>> > it's
>>> > >> > > > *really*
>>> > >> > > > > > >> hard to
>>> > >> > > > > > >> > > merge the wrong branch. If the list of commits
>>> that
>>> > >> comes
>>> > >> > up
>>> > >> > > > > > doesn't
>>> > >> > > > > > >> > look
>>> > >> > > > > > >> > > basically correct, you probably did something
>>> wrong--
>>> > >> trying
>>> > >> > > to
>>> > >> > > > > > rebase
>>> > >> > > > > > >> > onto
>>> > >> > > > > > >> > > the wrong branch will give you tons of commits,
>>> most of
>>> > >> > which
>>> > >> > > > > aren't
>>> > >> > > > > > >> > yours.
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> > > I think what you've been doing is fine, it's
>>> definitely
>>> > >> the
>>> > >> > > > right
>>> > >> > > > > > >> > approach
>>> > >> > > > > > >> > > if you're doing a merge strategy! I've just ended
>>> up
>>> > >> > > > gravitating
>>> > >> > > > > > to a
>>> > >> > > > > > >> > > rebase strategy over the years for the reasons I've
>>> > >> > mentioned.
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman
>>> <
>>> > >> > > > > > >> > > jordan@jordanzimmerman.com> wrote:
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up
>>> > several
>>> > >> > > > projects
>>> > >> > > > > > >> with
>>> > >> > > > > > >> > it
>>> > >> > > > > > >> > >> so I can’t even type the letters without breaking
>>> > into a
>>> > >> > > sweat.
>>> > >> > > > > > "git
>>> > >> > > > > > >> > rebase
>>> > >> > > > > > >> > >> -i” is a lot safer, though. Here’s what I’ve been
>>> > doing
>>> > >> -
>>> > >> > let
>>> > >> > > > me
>>> > >> > > > > > >> know if
>>> > >> > > > > > >> > >> it’s OK. For branches that are off of
>>> CURATOR-3.0, I
>>> > >> never
>>> > >> > > > merge
>>> > >> > > > > > >> > master. I
>>> > >> > > > > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”.
>>> In
>>> > >> fact,
>>> > >> > > > should
>>> > >> > > > > we
>>> > >> > > > > > >> > have a
>>> > >> > > > > > >> > >> branch naming scheme to enforce this?
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> -Jordan
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
>>> > >> > > > > > >> dragonsinth@apache.org)
>>> > >> > > > > > >> > >> wrote:
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> Correct. When I say "main" branch vs. "feature"
>>> > branch I
>>> > >> > just
>>> > >> > > > > mean
>>> > >> > > > > > >> the
>>> > >> > > > > > >> > >> stable branch everyone is working against (3.0 or
>>> > >> master)
>>> > >> > > vs. a
>>> > >> > > > > > >> feature
>>> > >> > > > > > >> > >> branch where you're actively working.
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> You'll get to a point in development where you'll
>>> > think
>>> > >> > "Hey,
>>> > >> > > > > there
>>> > >> > > > > > >> are
>>> > >> > > > > > >> > >> changes on the main branch I'm working against
>>> that I
>>> > >> > really
>>> > >> > > > need
>>> > >> > > > > > to
>>> > >> > > > > > >> > pull
>>> > >> > > > > > >> > >> into my feature branch." At that point
>>> (particularly
>>> > if
>>> > >> you
>>> > >> > > > have
>>> > >> > > > > an
>>> > >> > > > > > >> svn
>>> > >> > > > > > >> > >> background) you'll be tempted to merge the main
>>> branch
>>> > >> into
>>> > >> > > > your
>>> > >> > > > > > >> feature
>>> > >> > > > > > >> > >> branch. I would suggest not doing that, as it
>>> makes
>>> > the
>>> > >> > > history
>>> > >> > > > > > very
>>> > >> > > > > > >> > muddy
>>> > >> > > > > > >> > >> to follow. Instead, my workflow is usually more
>>> like
>>> > >> this:
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> Suppose I'm working on CURATOR-218. It was
>>> originally
>>> > >> > > branched
>>> > >> > > > > off
>>> > >> > > > > > >> 3.0,
>>> > >> > > > > > >> > >> and I want to pull in new changes.
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> git remote update
>>> > >> > > > > > >> > >> git rebase -i origin/CURATOR-3.0
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> This pulls up an editor that gives me the list of
>>> > >> commits
>>> > >> > to
>>> > >> > > > > > rebase.
>>> > >> > > > > > >> I
>>> > >> > > > > > >> > >> would typically exit out of the editor to at this
>>> > point
>>> > >> to
>>> > >> > > > accept
>>> > >> > > > > > the
>>> > >> > > > > > >> > >> commit list, but if I'm so inclined, I'll do
>>> things
>>> > like
>>> > >> > > > reorder
>>> > >> > > > > > the
>>> > >> > > > > > >> > list,
>>> > >> > > > > > >> > >> or squash commits like like "wip" or "minor
>>> reformat"
>>> > >> into
>>> > >> > a
>>> > >> > > > more
>>> > >> > > > > > >> > curated
>>> > >> > > > > > >> > >> set of logical commits.
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> Once you exit the editor, git goes through and
>>> applies
>>> > >> each
>>> > >> > > > > commit,
>>> > >> > > > > > >> one
>>> > >> > > > > > >> > at
>>> > >> > > > > > >> > >> a time, to the head of the target branch. It's
>>> like
>>> > >> picking
>>> > >> > > up
>>> > >> > > > > your
>>> > >> > > > > > >> > commit
>>> > >> > > > > > >> > >> chain and dumping it at the end of the target
>>> branch,
>>> > >> as if
>>> > >> > > all
>>> > >> > > > > > your
>>> > >> > > > > > >> > work
>>> > >> > > > > > >> > >> had been done against what's now the head of that
>>> > >> branch.
>>> > >> > > > You'll
>>> > >> > > > > > may
>>> > >> > > > > > >> > have
>>> > >> > > > > > >> > >> to fix conflicts along the way, but usually not
>>> much
>>> > >> more
>>> > >> > > than
>>> > >> > > > if
>>> > >> > > > > > you
>>> > >> > > > > > >> > did
>>> > >> > > > > > >> > >> it as a merge.
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> I'd encourage us to try this out a couple times
>>> and
>>> > get
>>> > >> a
>>> > >> > > feel
>>> > >> > > > > for
>>> > >> > > > > > >> the
>>> > >> > > > > > >> > >> rebase flow. It's a little more to get your head
>>> > around
>>> > >> at
>>> > >> > > > first,
>>> > >> > > > > > but
>>> > >> > > > > > >> > the
>>> > >> > > > > > >> > >> upside is you end up with really easy to follow
>>> commit
>>> > >> > > > histories,
>>> > >> > > > > > >> which
>>> > >> > > > > > >> > >> makes it way easier to untangle problems later if
>>> they
>>> > >> crop
>>> > >> > > up.
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan
>>> Zimmerman <
>>> > >> > > > > > >> > >> jordan@jordanzimmerman.com> wrote:
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >> > Can you explain this in detail? For me, I have
>>> some
>>> > >> > > features
>>> > >> > > > > that
>>> > >> > > > > > >> are
>>> > >> > > > > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a
>>> kind of
>>> > >> > > master.
>>> > >> > > > > The
>>> > >> > > > > > >> true
>>> > >> > > > > > >> > >> > “master” is Curator 2.x only, right?
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> > -Jordan
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
>>> > >> > > > > > >> dragonsinth@apache.org
>>> > >> > > > > > >> > )
>>> > >> > > > > > >> > >> > wrote:
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> > BTW: I noticed a couple of new commits
>>> > >> > > > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
>>> > >> > > > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27)
>>> where
>>> > 3.0
>>> > >> is
>>> > >> > > > > getting
>>> > >> > > > > > >> > merged
>>> > >> > > > > > >> > >> > into feature branches. Almost every project I've
>>> > been
>>> > >> on
>>> > >> > we
>>> > >> > > > > don't
>>> > >> > > > > > >> tend
>>> > >> > > > > > >> > >> to
>>> > >> > > > > > >> > >> > do that as it leads to confusing history (this
>>> isn't
>>> > >> just
>>> > >> > > > > > >> aesthetic,
>>> > >> > > > > > >> > it
>>> > >> > > > > > >> > >> > can
>>> > >> > > > > > >> > >> > get harder for tooling to figure out what
>>> happened).
>>> > >> If I
>>> > >> > > > want
>>> > >> > > > > to
>>> > >> > > > > > >> pull
>>> > >> > > > > > >> > >> > changes from the main branch into my feature
>>> > branch, I
>>> > >> > > would
>>> > >> > > > > > >> typically
>>> > >> > > > > > >> > >> > *rebase* my feature branch against the main
>>> branch.
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
>>> > >> > > > > > >> dragonsinth@apache.org>
>>> > >> > > > > > >> > >> > wrote:
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> > > Yeah, 217 & 161 were the first two big things
>>> in
>>> > >> 3.0.
>>> > >> > > > > > >> > >> > >
>>> > >> > > > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan
>>> Zimmerman
>>> > <
>>> > >> > > > > > >> > >> > > jordan@jordanzimmerman.com> wrote:
>>> > >> > > > > > >> > >> > >
>>> > >> > > > > > >> > >> > >> OK - Also, is CURATOR-161 complete? The
>>> issue is
>>> > >> still
>>> > >> > > > open
>>> > >> > > > > in
>>> > >> > > > > > >> > Jira.
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron
>>> > >> McKenzie (
>>> > >> > > > > > >> > >> > >> mckenzie.cam@gmail.com) wrote:
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >> Yes, I merged it in last week some time.
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan
>>> > Zimmerman <
>>> > >> > > > > > >> > >> > >> jordan@jordanzimmerman.com> wrote:
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >> > Scott, did CURATOR-217 get merged into the
>>> new
>>> > >> > > > > CURATOR-3.0?
>>> > >> > > > > > >> > >> > >> >
>>> > >> > > > > > >> > >> > >> > -Jordan
>>> > >> > > > > > >> > >> > >> >
>>> > >> > > > > > >> > >> > >> >
>>> > >> > > > > > >> > >> > >> >
>>> > >> > > > > > >> > >> > >>
>>> > >> > > > > > >> > >> > >
>>> > >> > > > > > >> > >> > >
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >> >
>>> > >> > > > > > >> > >>
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> > >
>>> > >> > > > > > >> >
>>> > >> > > > > > >>
>>> > >> > > > > > >
>>> > >> > > > > > >
>>> > >> > > > > >
>>> > >> > > > >
>>> > >> > > >
>>> > >> > >
>>> > >> >
>>> > >>
>>> > >
>>> > >
>>> >
>>>
>>
>>
>
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
I've had a bit of a look at it and the test seems very fragile. It already
has a bit of built in margin for error, but it relies on the consumers
being able to consume messages off the queue faster than they are produced.
If more than 20 messages end up on the queue at any time then test test
fails.
Anyway, I will raise a JIRA and we can discuss there.
On Wed, Aug 26, 2015 at 9:29 AM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Thanks Mike,
> On master. I'll have a bit of a look into it and let you know. I think
> that it's a race condition based on how the test is structured.
> cheers
>
> On Wed, Aug 26, 2015 at 9:18 AM, Mike Drob <ma...@cloudera.com> wrote:
>
>> Is this on 3.0 or master? Can you create a JIRA with some log output?
>>
>> On Tue, Aug 25, 2015 at 6:15 PM, Cameron McKenzie <mckenzie.cam@gmail.com
>> >
>> wrote:
>>
>> > Is anyone seeing fairly consistent failure of the
>> >
>> > TestBoundedDistributedQueue.testMulti:184
>> >
>> > test? When I run from inside eclipse in isolation it seems ok, but
>> running
>> > a 'mvn test' seems to fail on this test with some consistency. The
>> changes
>> > for CURATOR-167 certainly haven't caused this to happen.
>> > cheers
>> >
>> > On Wed, Aug 26, 2015 at 7:45 AM, Cameron McKenzie <
>> mckenzie.cam@gmail.com>
>> > wrote:
>> >
>> > > Thanks Scott,
>> > > I will merge into master.
>> > > cheers
>> > >
>> > > On Wed, Aug 26, 2015 at 1:00 AM, Scott Blum <dr...@gmail.com>
>> > wrote:
>> > >
>> > >> Yep, that looks perfect. Is CURATOR-167 done? If so, we can just
>> > >> fast-foward merge it into master now.
>> > >>
>> > >> On Tue, Aug 25, 2015 at 12:11 AM, Cameron McKenzie <
>> > >> mckenzie.cam@gmail.com>
>> > >> wrote:
>> > >>
>> > >> > Thanks Scott,
>> > >> > Done, would you mind checking the origin/CURATOR-167 to make sure
>> > that I
>> > >> > haven't done anything wrong! I have done a git pull on a different
>> > >> machine
>> > >> > and it seems to be ok.
>> > >> > cheers
>> > >> >
>> > >> > On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum <dragonsinth@gmail.com
>> >
>> > >> wrote:
>> > >> >
>> > >> > > You just force push your branch.
>> > >> > >
>> > >> > > If it's your feature branch, and you know you have it in a good
>> > state
>> > >> > > locally, you can just force push the remote branch into the same
>> > >> state.
>> > >> > >
>> > >> > > You'd never want to do that to master, a release branch, or
>> someone
>> > >> > else's
>> > >> > > branch.
>> > >> > > On Aug 24, 2015 11:15 PM, "Cameron McKenzie" <
>> > mckenzie.cam@gmail.com>
>> > >> > > wrote:
>> > >> > >
>> > >> > > > Thanks Mike,
>> > >> > > > That was a good description. The CURATOR-167 branch is
>> definitely
>> > >> there
>> > >> > > as
>> > >> > > > it's been a pull request for the last few months. So, I'll
>> await
>> > >> your
>> > >> > > > thoughts in the morning. Alternatively, I can just merge master
>> > >> instead
>> > >> > > of
>> > >> > > > rebasing it.
>> > >> > > >
>> > >> > > > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <
>> madrob@cloudera.com>
>> > >> > wrote:
>> > >> > > >
>> > >> > > > > Yea, that's the big downside with rebasing, is that remotes
>> > don't
>> > >> > > exactly
>> > >> > > > > keep up with the history. I'm going to try to explain this as
>> > best
>> > >> > as I
>> > >> > > > > can, but usually I point people towards this excellent "Git
>> for
>> > >> Ages
>> > >> > 4
>> > >> > > > and
>> > >> > > > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he
>> > talks
>> > >> > about
>> > >> > > > > rebases at the very very end, around the 1:30 mark.
>> > >> > > > >
>> > >> > > > > Essentially, your current version of the branch does not have
>> > the
>> > >> > > remote
>> > >> > > > > version of the as an ancestor. Which is correct, when you did
>> > the
>> > >> > > rebase,
>> > >> > > > > you wrote a new commit lineage.
>> > >> > > > >
>> > >> > > > > I didn't realize that there was already a CURATOR-167 branch
>> > >> pushed
>> > >> > to
>> > >> > > > the
>> > >> > > > > repo when I gave you those steps. I'll have to look at what's
>> > >> going
>> > >> > on
>> > >> > > > with
>> > >> > > > > a fresh set of eyes in the morning.
>> > >> > > > >
>> > >> > > > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <
>> > >> > > > mckenzie.cam@gmail.com>
>> > >> > > > > wrote:
>> > >> > > > >
>> > >> > > > > > I just tried this and obviously I'm doing something wrong.
>> > >> > > > > >
>> > >> > > > > > git checkout CURATOR-167
>> > >> > > > > > git pull
>> > >> > > > > > git rebase -i origin/master
>> > >> > > > > >
>> > >> > > > > > #This gives me a dialog with one commit with pick
>> > >> > > > > > Save and exit
>> > >> > > > > > #This gives a merge conflict and leaves me in a detached
>> head
>> > >> state
>> > >> > > (I
>> > >> > > > > > presume this is ok).
>> > >> > > > > > Fix up the merge conflict
>> > >> > > > > > git rebase --continue
>> > >> > > > > > #This gives me a dialog to commit the changes
>> > >> > > > > > Save and exit
>> > >> > > > > > #Everything seems fine at this point. Builds ok, tests run
>> ok.
>> > >> > > > > >
>> > >> > > > > > git push
>> > >> > > > > >
>> > >> > > > > > ! [rejected] CURATOR-167 -> CURATOR-167
>> > >> (non-fast-forward)
>> > >> > > > > > error: failed to push some refs to '
>> > >> > > > > > https://git-wip-us.apache.org/repos/asf/curator.git'
>> > >> > > > > > hint: Updates were rejected because the tip of your current
>> > >> branch
>> > >> > is
>> > >> > > > > > behind
>> > >> > > > > > hint: its remote counterpart. Integrate the remote changes
>> > (e.g.
>> > >> > > > > > hint: 'git pull ...') before pushing again.
>> > >> > > > > > hint: See the 'Note about fast-forwards' in 'git push
>> --help'
>> > >> for
>> > >> > > > > details.
>> > >> > > > > >
>> > >> > > > > > There have been no changes on the branch since I did the
>> pull
>> > >> > before
>> > >> > > > the
>> > >> > > > > > rebase.
>> > >> > > > > >
>> > >> > > > > > Any ideas?
>> > >> > > > > >
>> > >> > > > > >
>> > >> > > > > >
>> > >> > > > > >
>> > >> > > > > >
>> > >> > > > > >
>> > >> > > > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <
>> > >> > > > > mckenzie.cam@gmail.com>
>> > >> > > > > > wrote:
>> > >> > > > > >
>> > >> > > > > > > Thanks Mike,
>> > >> > > > > > > Will give it a spin today some time.
>> > >> > > > > > > cheers
>> > >> > > > > > >
>> > >> > > > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <
>> > >> madrob@cloudera.com>
>> > >> > > > > wrote:
>> > >> > > > > > >
>> > >> > > > > > >> if you're going to tray that, here's what you want to do
>> > >> > (assuming
>> > >> > > > > > command
>> > >> > > > > > >> line)
>> > >> > > > > > >>
>> > >> > > > > > >> git checkout CURATOR-167 # start with the branch that
>> you
>> > are
>> > >> > > > changing
>> > >> > > > > > >> git rebase -i master # rebase the current branch on top
>> of
>> > >> the
>> > >> > > given
>> > >> > > > > > >> branch
>> > >> > > > > > >>
>> > >> > > > > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
>> > >> > > > > > mckenzie.cam@gmail.com
>> > >> > > > > > >> >
>> > >> > > > > > >> wrote:
>> > >> > > > > > >>
>> > >> > > > > > >> > Scott,
>> > >> > > > > > >> > I've been using a similar approach to Jordan given
>> that's
>> > >> what
>> > >> > > I'm
>> > >> > > > > > used
>> > >> > > > > > >> to,
>> > >> > > > > > >> > but I'm happy to try your approach. I'm going to try
>> and
>> > >> fix
>> > >> > up
>> > >> > > > > > >> CURATOR-167
>> > >> > > > > > >> > as it will no longer cleanly merge (it's been sitting
>> > >> there a
>> > >> > > > > while).
>> > >> > > > > > >> So, I
>> > >> > > > > > >> > should rebase master into the CURATOR-167 branch?
>> > >> > > > > > >> > cheers
>> > >> > > > > > >> >
>> > >> > > > > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <
>> > >> > > > dragonsinth@apache.org
>> > >> > > > > >
>> > >> > > > > > >> > wrote:
>> > >> > > > > > >> >
>> > >> > > > > > >> > > LOL! So sorry to hear that. Yeah, it's definitely
>> > >> possible
>> > >> > > to
>> > >> > > > > mess
>> > >> > > > > > >> > > things up badly. If I'm doing something
>> particularly
>> > >> risky,
>> > >> > > > I'll
>> > >> > > > > > just
>> > >> > > > > > >> > "git
>> > >> > > > > > >> > > branch original" before I start, so as to leave a
>> > branch
>> > >> > > pointer
>> > >> > > > > at
>> > >> > > > > > my
>> > >> > > > > > >> > > start point as a safe recovery if it goes south. I
>> > also
>> > >> use
>> > >> > > > gitk
>> > >> > > > > to
>> > >> > > > > > >> > > visualize sometimes.
>> > >> > > > > > >> > >
>> > >> > > > > > >> > > Another major selling point for rebase (-i) is that
>> > it's
>> > >> > > > *really*
>> > >> > > > > > >> hard to
>> > >> > > > > > >> > > merge the wrong branch. If the list of commits that
>> > >> comes
>> > >> > up
>> > >> > > > > > doesn't
>> > >> > > > > > >> > look
>> > >> > > > > > >> > > basically correct, you probably did something
>> wrong--
>> > >> trying
>> > >> > > to
>> > >> > > > > > rebase
>> > >> > > > > > >> > onto
>> > >> > > > > > >> > > the wrong branch will give you tons of commits,
>> most of
>> > >> > which
>> > >> > > > > aren't
>> > >> > > > > > >> > yours.
>> > >> > > > > > >> > >
>> > >> > > > > > >> > > I think what you've been doing is fine, it's
>> definitely
>> > >> the
>> > >> > > > right
>> > >> > > > > > >> > approach
>> > >> > > > > > >> > > if you're doing a merge strategy! I've just ended
>> up
>> > >> > > > gravitating
>> > >> > > > > > to a
>> > >> > > > > > >> > > rebase strategy over the years for the reasons I've
>> > >> > mentioned.
>> > >> > > > > > >> > >
>> > >> > > > > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
>> > >> > > > > > >> > > jordan@jordanzimmerman.com> wrote:
>> > >> > > > > > >> > >
>> > >> > > > > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up
>> > several
>> > >> > > > projects
>> > >> > > > > > >> with
>> > >> > > > > > >> > it
>> > >> > > > > > >> > >> so I can’t even type the letters without breaking
>> > into a
>> > >> > > sweat.
>> > >> > > > > > "git
>> > >> > > > > > >> > rebase
>> > >> > > > > > >> > >> -i” is a lot safer, though. Here’s what I’ve been
>> > doing
>> > >> -
>> > >> > let
>> > >> > > > me
>> > >> > > > > > >> know if
>> > >> > > > > > >> > >> it’s OK. For branches that are off of CURATOR-3.0,
>> I
>> > >> never
>> > >> > > > merge
>> > >> > > > > > >> > master. I
>> > >> > > > > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In
>> > >> fact,
>> > >> > > > should
>> > >> > > > > we
>> > >> > > > > > >> > have a
>> > >> > > > > > >> > >> branch naming scheme to enforce this?
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> -Jordan
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
>> > >> > > > > > >> dragonsinth@apache.org)
>> > >> > > > > > >> > >> wrote:
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> Correct. When I say "main" branch vs. "feature"
>> > branch I
>> > >> > just
>> > >> > > > > mean
>> > >> > > > > > >> the
>> > >> > > > > > >> > >> stable branch everyone is working against (3.0 or
>> > >> master)
>> > >> > > vs. a
>> > >> > > > > > >> feature
>> > >> > > > > > >> > >> branch where you're actively working.
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> You'll get to a point in development where you'll
>> > think
>> > >> > "Hey,
>> > >> > > > > there
>> > >> > > > > > >> are
>> > >> > > > > > >> > >> changes on the main branch I'm working against
>> that I
>> > >> > really
>> > >> > > > need
>> > >> > > > > > to
>> > >> > > > > > >> > pull
>> > >> > > > > > >> > >> into my feature branch." At that point
>> (particularly
>> > if
>> > >> you
>> > >> > > > have
>> > >> > > > > an
>> > >> > > > > > >> svn
>> > >> > > > > > >> > >> background) you'll be tempted to merge the main
>> branch
>> > >> into
>> > >> > > > your
>> > >> > > > > > >> feature
>> > >> > > > > > >> > >> branch. I would suggest not doing that, as it makes
>> > the
>> > >> > > history
>> > >> > > > > > very
>> > >> > > > > > >> > muddy
>> > >> > > > > > >> > >> to follow. Instead, my workflow is usually more
>> like
>> > >> this:
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> Suppose I'm working on CURATOR-218. It was
>> originally
>> > >> > > branched
>> > >> > > > > off
>> > >> > > > > > >> 3.0,
>> > >> > > > > > >> > >> and I want to pull in new changes.
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> git remote update
>> > >> > > > > > >> > >> git rebase -i origin/CURATOR-3.0
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> This pulls up an editor that gives me the list of
>> > >> commits
>> > >> > to
>> > >> > > > > > rebase.
>> > >> > > > > > >> I
>> > >> > > > > > >> > >> would typically exit out of the editor to at this
>> > point
>> > >> to
>> > >> > > > accept
>> > >> > > > > > the
>> > >> > > > > > >> > >> commit list, but if I'm so inclined, I'll do things
>> > like
>> > >> > > > reorder
>> > >> > > > > > the
>> > >> > > > > > >> > list,
>> > >> > > > > > >> > >> or squash commits like like "wip" or "minor
>> reformat"
>> > >> into
>> > >> > a
>> > >> > > > more
>> > >> > > > > > >> > curated
>> > >> > > > > > >> > >> set of logical commits.
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> Once you exit the editor, git goes through and
>> applies
>> > >> each
>> > >> > > > > commit,
>> > >> > > > > > >> one
>> > >> > > > > > >> > at
>> > >> > > > > > >> > >> a time, to the head of the target branch. It's like
>> > >> picking
>> > >> > > up
>> > >> > > > > your
>> > >> > > > > > >> > commit
>> > >> > > > > > >> > >> chain and dumping it at the end of the target
>> branch,
>> > >> as if
>> > >> > > all
>> > >> > > > > > your
>> > >> > > > > > >> > work
>> > >> > > > > > >> > >> had been done against what's now the head of that
>> > >> branch.
>> > >> > > > You'll
>> > >> > > > > > may
>> > >> > > > > > >> > have
>> > >> > > > > > >> > >> to fix conflicts along the way, but usually not
>> much
>> > >> more
>> > >> > > than
>> > >> > > > if
>> > >> > > > > > you
>> > >> > > > > > >> > did
>> > >> > > > > > >> > >> it as a merge.
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> I'd encourage us to try this out a couple times and
>> > get
>> > >> a
>> > >> > > feel
>> > >> > > > > for
>> > >> > > > > > >> the
>> > >> > > > > > >> > >> rebase flow. It's a little more to get your head
>> > around
>> > >> at
>> > >> > > > first,
>> > >> > > > > > but
>> > >> > > > > > >> > the
>> > >> > > > > > >> > >> upside is you end up with really easy to follow
>> commit
>> > >> > > > histories,
>> > >> > > > > > >> which
>> > >> > > > > > >> > >> makes it way easier to untangle problems later if
>> they
>> > >> crop
>> > >> > > up.
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman
>> <
>> > >> > > > > > >> > >> jordan@jordanzimmerman.com> wrote:
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >> > Can you explain this in detail? For me, I have
>> some
>> > >> > > features
>> > >> > > > > that
>> > >> > > > > > >> are
>> > >> > > > > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a
>> kind of
>> > >> > > master.
>> > >> > > > > The
>> > >> > > > > > >> true
>> > >> > > > > > >> > >> > “master” is Curator 2.x only, right?
>> > >> > > > > > >> > >> >
>> > >> > > > > > >> > >> > -Jordan
>> > >> > > > > > >> > >> >
>> > >> > > > > > >> > >> >
>> > >> > > > > > >> > >> >
>> > >> > > > > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
>> > >> > > > > > >> dragonsinth@apache.org
>> > >> > > > > > >> > )
>> > >> > > > > > >> > >> > wrote:
>> > >> > > > > > >> > >> >
>> > >> > > > > > >> > >> > BTW: I noticed a couple of new commits
>> > >> > > > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
>> > >> > > > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where
>> > 3.0
>> > >> is
>> > >> > > > > getting
>> > >> > > > > > >> > merged
>> > >> > > > > > >> > >> > into feature branches. Almost every project I've
>> > been
>> > >> on
>> > >> > we
>> > >> > > > > don't
>> > >> > > > > > >> tend
>> > >> > > > > > >> > >> to
>> > >> > > > > > >> > >> > do that as it leads to confusing history (this
>> isn't
>> > >> just
>> > >> > > > > > >> aesthetic,
>> > >> > > > > > >> > it
>> > >> > > > > > >> > >> > can
>> > >> > > > > > >> > >> > get harder for tooling to figure out what
>> happened).
>> > >> If I
>> > >> > > > want
>> > >> > > > > to
>> > >> > > > > > >> pull
>> > >> > > > > > >> > >> > changes from the main branch into my feature
>> > branch, I
>> > >> > > would
>> > >> > > > > > >> typically
>> > >> > > > > > >> > >> > *rebase* my feature branch against the main
>> branch.
>> > >> > > > > > >> > >> >
>> > >> > > > > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
>> > >> > > > > > >> dragonsinth@apache.org>
>> > >> > > > > > >> > >> > wrote:
>> > >> > > > > > >> > >> >
>> > >> > > > > > >> > >> > > Yeah, 217 & 161 were the first two big things
>> in
>> > >> 3.0.
>> > >> > > > > > >> > >> > >
>> > >> > > > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan
>> Zimmerman
>> > <
>> > >> > > > > > >> > >> > > jordan@jordanzimmerman.com> wrote:
>> > >> > > > > > >> > >> > >
>> > >> > > > > > >> > >> > >> OK - Also, is CURATOR-161 complete? The issue
>> is
>> > >> still
>> > >> > > > open
>> > >> > > > > in
>> > >> > > > > > >> > Jira.
>> > >> > > > > > >> > >> > >>
>> > >> > > > > > >> > >> > >>
>> > >> > > > > > >> > >> > >>
>> > >> > > > > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron
>> > >> McKenzie (
>> > >> > > > > > >> > >> > >> mckenzie.cam@gmail.com) wrote:
>> > >> > > > > > >> > >> > >>
>> > >> > > > > > >> > >> > >> Yes, I merged it in last week some time.
>> > >> > > > > > >> > >> > >>
>> > >> > > > > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan
>> > Zimmerman <
>> > >> > > > > > >> > >> > >> jordan@jordanzimmerman.com> wrote:
>> > >> > > > > > >> > >> > >>
>> > >> > > > > > >> > >> > >> > Scott, did CURATOR-217 get merged into the
>> new
>> > >> > > > > CURATOR-3.0?
>> > >> > > > > > >> > >> > >> >
>> > >> > > > > > >> > >> > >> > -Jordan
>> > >> > > > > > >> > >> > >> >
>> > >> > > > > > >> > >> > >> >
>> > >> > > > > > >> > >> > >> >
>> > >> > > > > > >> > >> > >>
>> > >> > > > > > >> > >> > >
>> > >> > > > > > >> > >> > >
>> > >> > > > > > >> > >> >
>> > >> > > > > > >> > >> >
>> > >> > > > > > >> > >>
>> > >> > > > > > >> > >
>> > >> > > > > > >> > >
>> > >> > > > > > >> >
>> > >> > > > > > >>
>> > >> > > > > > >
>> > >> > > > > > >
>> > >> > > > > >
>> > >> > > > >
>> > >> > > >
>> > >> > >
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
>
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
Thanks Mike,
On master. I'll have a bit of a look into it and let you know. I think that
it's a race condition based on how the test is structured.
cheers
On Wed, Aug 26, 2015 at 9:18 AM, Mike Drob <ma...@cloudera.com> wrote:
> Is this on 3.0 or master? Can you create a JIRA with some log output?
>
> On Tue, Aug 25, 2015 at 6:15 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
> > Is anyone seeing fairly consistent failure of the
> >
> > TestBoundedDistributedQueue.testMulti:184
> >
> > test? When I run from inside eclipse in isolation it seems ok, but
> running
> > a 'mvn test' seems to fail on this test with some consistency. The
> changes
> > for CURATOR-167 certainly haven't caused this to happen.
> > cheers
> >
> > On Wed, Aug 26, 2015 at 7:45 AM, Cameron McKenzie <
> mckenzie.cam@gmail.com>
> > wrote:
> >
> > > Thanks Scott,
> > > I will merge into master.
> > > cheers
> > >
> > > On Wed, Aug 26, 2015 at 1:00 AM, Scott Blum <dr...@gmail.com>
> > wrote:
> > >
> > >> Yep, that looks perfect. Is CURATOR-167 done? If so, we can just
> > >> fast-foward merge it into master now.
> > >>
> > >> On Tue, Aug 25, 2015 at 12:11 AM, Cameron McKenzie <
> > >> mckenzie.cam@gmail.com>
> > >> wrote:
> > >>
> > >> > Thanks Scott,
> > >> > Done, would you mind checking the origin/CURATOR-167 to make sure
> > that I
> > >> > haven't done anything wrong! I have done a git pull on a different
> > >> machine
> > >> > and it seems to be ok.
> > >> > cheers
> > >> >
> > >> > On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum <dr...@gmail.com>
> > >> wrote:
> > >> >
> > >> > > You just force push your branch.
> > >> > >
> > >> > > If it's your feature branch, and you know you have it in a good
> > state
> > >> > > locally, you can just force push the remote branch into the same
> > >> state.
> > >> > >
> > >> > > You'd never want to do that to master, a release branch, or
> someone
> > >> > else's
> > >> > > branch.
> > >> > > On Aug 24, 2015 11:15 PM, "Cameron McKenzie" <
> > mckenzie.cam@gmail.com>
> > >> > > wrote:
> > >> > >
> > >> > > > Thanks Mike,
> > >> > > > That was a good description. The CURATOR-167 branch is
> definitely
> > >> there
> > >> > > as
> > >> > > > it's been a pull request for the last few months. So, I'll await
> > >> your
> > >> > > > thoughts in the morning. Alternatively, I can just merge master
> > >> instead
> > >> > > of
> > >> > > > rebasing it.
> > >> > > >
> > >> > > > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <madrob@cloudera.com
> >
> > >> > wrote:
> > >> > > >
> > >> > > > > Yea, that's the big downside with rebasing, is that remotes
> > don't
> > >> > > exactly
> > >> > > > > keep up with the history. I'm going to try to explain this as
> > best
> > >> > as I
> > >> > > > > can, but usually I point people towards this excellent "Git
> for
> > >> Ages
> > >> > 4
> > >> > > > and
> > >> > > > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he
> > talks
> > >> > about
> > >> > > > > rebases at the very very end, around the 1:30 mark.
> > >> > > > >
> > >> > > > > Essentially, your current version of the branch does not have
> > the
> > >> > > remote
> > >> > > > > version of the as an ancestor. Which is correct, when you did
> > the
> > >> > > rebase,
> > >> > > > > you wrote a new commit lineage.
> > >> > > > >
> > >> > > > > I didn't realize that there was already a CURATOR-167 branch
> > >> pushed
> > >> > to
> > >> > > > the
> > >> > > > > repo when I gave you those steps. I'll have to look at what's
> > >> going
> > >> > on
> > >> > > > with
> > >> > > > > a fresh set of eyes in the morning.
> > >> > > > >
> > >> > > > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <
> > >> > > > mckenzie.cam@gmail.com>
> > >> > > > > wrote:
> > >> > > > >
> > >> > > > > > I just tried this and obviously I'm doing something wrong.
> > >> > > > > >
> > >> > > > > > git checkout CURATOR-167
> > >> > > > > > git pull
> > >> > > > > > git rebase -i origin/master
> > >> > > > > >
> > >> > > > > > #This gives me a dialog with one commit with pick
> > >> > > > > > Save and exit
> > >> > > > > > #This gives a merge conflict and leaves me in a detached
> head
> > >> state
> > >> > > (I
> > >> > > > > > presume this is ok).
> > >> > > > > > Fix up the merge conflict
> > >> > > > > > git rebase --continue
> > >> > > > > > #This gives me a dialog to commit the changes
> > >> > > > > > Save and exit
> > >> > > > > > #Everything seems fine at this point. Builds ok, tests run
> ok.
> > >> > > > > >
> > >> > > > > > git push
> > >> > > > > >
> > >> > > > > > ! [rejected] CURATOR-167 -> CURATOR-167
> > >> (non-fast-forward)
> > >> > > > > > error: failed to push some refs to '
> > >> > > > > > https://git-wip-us.apache.org/repos/asf/curator.git'
> > >> > > > > > hint: Updates were rejected because the tip of your current
> > >> branch
> > >> > is
> > >> > > > > > behind
> > >> > > > > > hint: its remote counterpart. Integrate the remote changes
> > (e.g.
> > >> > > > > > hint: 'git pull ...') before pushing again.
> > >> > > > > > hint: See the 'Note about fast-forwards' in 'git push
> --help'
> > >> for
> > >> > > > > details.
> > >> > > > > >
> > >> > > > > > There have been no changes on the branch since I did the
> pull
> > >> > before
> > >> > > > the
> > >> > > > > > rebase.
> > >> > > > > >
> > >> > > > > > Any ideas?
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > >
> > >> > > > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <
> > >> > > > > mckenzie.cam@gmail.com>
> > >> > > > > > wrote:
> > >> > > > > >
> > >> > > > > > > Thanks Mike,
> > >> > > > > > > Will give it a spin today some time.
> > >> > > > > > > cheers
> > >> > > > > > >
> > >> > > > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <
> > >> madrob@cloudera.com>
> > >> > > > > wrote:
> > >> > > > > > >
> > >> > > > > > >> if you're going to tray that, here's what you want to do
> > >> > (assuming
> > >> > > > > > command
> > >> > > > > > >> line)
> > >> > > > > > >>
> > >> > > > > > >> git checkout CURATOR-167 # start with the branch that you
> > are
> > >> > > > changing
> > >> > > > > > >> git rebase -i master # rebase the current branch on top
> of
> > >> the
> > >> > > given
> > >> > > > > > >> branch
> > >> > > > > > >>
> > >> > > > > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
> > >> > > > > > mckenzie.cam@gmail.com
> > >> > > > > > >> >
> > >> > > > > > >> wrote:
> > >> > > > > > >>
> > >> > > > > > >> > Scott,
> > >> > > > > > >> > I've been using a similar approach to Jordan given
> that's
> > >> what
> > >> > > I'm
> > >> > > > > > used
> > >> > > > > > >> to,
> > >> > > > > > >> > but I'm happy to try your approach. I'm going to try
> and
> > >> fix
> > >> > up
> > >> > > > > > >> CURATOR-167
> > >> > > > > > >> > as it will no longer cleanly merge (it's been sitting
> > >> there a
> > >> > > > > while).
> > >> > > > > > >> So, I
> > >> > > > > > >> > should rebase master into the CURATOR-167 branch?
> > >> > > > > > >> > cheers
> > >> > > > > > >> >
> > >> > > > > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <
> > >> > > > dragonsinth@apache.org
> > >> > > > > >
> > >> > > > > > >> > wrote:
> > >> > > > > > >> >
> > >> > > > > > >> > > LOL! So sorry to hear that. Yeah, it's definitely
> > >> possible
> > >> > > to
> > >> > > > > mess
> > >> > > > > > >> > > things up badly. If I'm doing something particularly
> > >> risky,
> > >> > > > I'll
> > >> > > > > > just
> > >> > > > > > >> > "git
> > >> > > > > > >> > > branch original" before I start, so as to leave a
> > branch
> > >> > > pointer
> > >> > > > > at
> > >> > > > > > my
> > >> > > > > > >> > > start point as a safe recovery if it goes south. I
> > also
> > >> use
> > >> > > > gitk
> > >> > > > > to
> > >> > > > > > >> > > visualize sometimes.
> > >> > > > > > >> > >
> > >> > > > > > >> > > Another major selling point for rebase (-i) is that
> > it's
> > >> > > > *really*
> > >> > > > > > >> hard to
> > >> > > > > > >> > > merge the wrong branch. If the list of commits that
> > >> comes
> > >> > up
> > >> > > > > > doesn't
> > >> > > > > > >> > look
> > >> > > > > > >> > > basically correct, you probably did something wrong--
> > >> trying
> > >> > > to
> > >> > > > > > rebase
> > >> > > > > > >> > onto
> > >> > > > > > >> > > the wrong branch will give you tons of commits, most
> of
> > >> > which
> > >> > > > > aren't
> > >> > > > > > >> > yours.
> > >> > > > > > >> > >
> > >> > > > > > >> > > I think what you've been doing is fine, it's
> definitely
> > >> the
> > >> > > > right
> > >> > > > > > >> > approach
> > >> > > > > > >> > > if you're doing a merge strategy! I've just ended up
> > >> > > > gravitating
> > >> > > > > > to a
> > >> > > > > > >> > > rebase strategy over the years for the reasons I've
> > >> > mentioned.
> > >> > > > > > >> > >
> > >> > > > > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> > >> > > > > > >> > > jordan@jordanzimmerman.com> wrote:
> > >> > > > > > >> > >
> > >> > > > > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up
> > several
> > >> > > > projects
> > >> > > > > > >> with
> > >> > > > > > >> > it
> > >> > > > > > >> > >> so I can’t even type the letters without breaking
> > into a
> > >> > > sweat.
> > >> > > > > > "git
> > >> > > > > > >> > rebase
> > >> > > > > > >> > >> -i” is a lot safer, though. Here’s what I’ve been
> > doing
> > >> -
> > >> > let
> > >> > > > me
> > >> > > > > > >> know if
> > >> > > > > > >> > >> it’s OK. For branches that are off of CURATOR-3.0, I
> > >> never
> > >> > > > merge
> > >> > > > > > >> > master. I
> > >> > > > > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In
> > >> fact,
> > >> > > > should
> > >> > > > > we
> > >> > > > > > >> > have a
> > >> > > > > > >> > >> branch naming scheme to enforce this?
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> -Jordan
> > >> > > > > > >> > >>
> > >> > > > > > >> > >>
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
> > >> > > > > > >> dragonsinth@apache.org)
> > >> > > > > > >> > >> wrote:
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> Correct. When I say "main" branch vs. "feature"
> > branch I
> > >> > just
> > >> > > > > mean
> > >> > > > > > >> the
> > >> > > > > > >> > >> stable branch everyone is working against (3.0 or
> > >> master)
> > >> > > vs. a
> > >> > > > > > >> feature
> > >> > > > > > >> > >> branch where you're actively working.
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> You'll get to a point in development where you'll
> > think
> > >> > "Hey,
> > >> > > > > there
> > >> > > > > > >> are
> > >> > > > > > >> > >> changes on the main branch I'm working against that
> I
> > >> > really
> > >> > > > need
> > >> > > > > > to
> > >> > > > > > >> > pull
> > >> > > > > > >> > >> into my feature branch." At that point (particularly
> > if
> > >> you
> > >> > > > have
> > >> > > > > an
> > >> > > > > > >> svn
> > >> > > > > > >> > >> background) you'll be tempted to merge the main
> branch
> > >> into
> > >> > > > your
> > >> > > > > > >> feature
> > >> > > > > > >> > >> branch. I would suggest not doing that, as it makes
> > the
> > >> > > history
> > >> > > > > > very
> > >> > > > > > >> > muddy
> > >> > > > > > >> > >> to follow. Instead, my workflow is usually more like
> > >> this:
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> Suppose I'm working on CURATOR-218. It was
> originally
> > >> > > branched
> > >> > > > > off
> > >> > > > > > >> 3.0,
> > >> > > > > > >> > >> and I want to pull in new changes.
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> git remote update
> > >> > > > > > >> > >> git rebase -i origin/CURATOR-3.0
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> This pulls up an editor that gives me the list of
> > >> commits
> > >> > to
> > >> > > > > > rebase.
> > >> > > > > > >> I
> > >> > > > > > >> > >> would typically exit out of the editor to at this
> > point
> > >> to
> > >> > > > accept
> > >> > > > > > the
> > >> > > > > > >> > >> commit list, but if I'm so inclined, I'll do things
> > like
> > >> > > > reorder
> > >> > > > > > the
> > >> > > > > > >> > list,
> > >> > > > > > >> > >> or squash commits like like "wip" or "minor
> reformat"
> > >> into
> > >> > a
> > >> > > > more
> > >> > > > > > >> > curated
> > >> > > > > > >> > >> set of logical commits.
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> Once you exit the editor, git goes through and
> applies
> > >> each
> > >> > > > > commit,
> > >> > > > > > >> one
> > >> > > > > > >> > at
> > >> > > > > > >> > >> a time, to the head of the target branch. It's like
> > >> picking
> > >> > > up
> > >> > > > > your
> > >> > > > > > >> > commit
> > >> > > > > > >> > >> chain and dumping it at the end of the target
> branch,
> > >> as if
> > >> > > all
> > >> > > > > > your
> > >> > > > > > >> > work
> > >> > > > > > >> > >> had been done against what's now the head of that
> > >> branch.
> > >> > > > You'll
> > >> > > > > > may
> > >> > > > > > >> > have
> > >> > > > > > >> > >> to fix conflicts along the way, but usually not much
> > >> more
> > >> > > than
> > >> > > > if
> > >> > > > > > you
> > >> > > > > > >> > did
> > >> > > > > > >> > >> it as a merge.
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> I'd encourage us to try this out a couple times and
> > get
> > >> a
> > >> > > feel
> > >> > > > > for
> > >> > > > > > >> the
> > >> > > > > > >> > >> rebase flow. It's a little more to get your head
> > around
> > >> at
> > >> > > > first,
> > >> > > > > > but
> > >> > > > > > >> > the
> > >> > > > > > >> > >> upside is you end up with really easy to follow
> commit
> > >> > > > histories,
> > >> > > > > > >> which
> > >> > > > > > >> > >> makes it way easier to untangle problems later if
> they
> > >> crop
> > >> > > up.
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> > >> > > > > > >> > >> jordan@jordanzimmerman.com> wrote:
> > >> > > > > > >> > >>
> > >> > > > > > >> > >> > Can you explain this in detail? For me, I have
> some
> > >> > > features
> > >> > > > > that
> > >> > > > > > >> are
> > >> > > > > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind
> of
> > >> > > master.
> > >> > > > > The
> > >> > > > > > >> true
> > >> > > > > > >> > >> > “master” is Curator 2.x only, right?
> > >> > > > > > >> > >> >
> > >> > > > > > >> > >> > -Jordan
> > >> > > > > > >> > >> >
> > >> > > > > > >> > >> >
> > >> > > > > > >> > >> >
> > >> > > > > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
> > >> > > > > > >> dragonsinth@apache.org
> > >> > > > > > >> > )
> > >> > > > > > >> > >> > wrote:
> > >> > > > > > >> > >> >
> > >> > > > > > >> > >> > BTW: I noticed a couple of new commits
> > >> > > > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> > >> > > > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where
> > 3.0
> > >> is
> > >> > > > > getting
> > >> > > > > > >> > merged
> > >> > > > > > >> > >> > into feature branches. Almost every project I've
> > been
> > >> on
> > >> > we
> > >> > > > > don't
> > >> > > > > > >> tend
> > >> > > > > > >> > >> to
> > >> > > > > > >> > >> > do that as it leads to confusing history (this
> isn't
> > >> just
> > >> > > > > > >> aesthetic,
> > >> > > > > > >> > it
> > >> > > > > > >> > >> > can
> > >> > > > > > >> > >> > get harder for tooling to figure out what
> happened).
> > >> If I
> > >> > > > want
> > >> > > > > to
> > >> > > > > > >> pull
> > >> > > > > > >> > >> > changes from the main branch into my feature
> > branch, I
> > >> > > would
> > >> > > > > > >> typically
> > >> > > > > > >> > >> > *rebase* my feature branch against the main
> branch.
> > >> > > > > > >> > >> >
> > >> > > > > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
> > >> > > > > > >> dragonsinth@apache.org>
> > >> > > > > > >> > >> > wrote:
> > >> > > > > > >> > >> >
> > >> > > > > > >> > >> > > Yeah, 217 & 161 were the first two big things in
> > >> 3.0.
> > >> > > > > > >> > >> > >
> > >> > > > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan
> Zimmerman
> > <
> > >> > > > > > >> > >> > > jordan@jordanzimmerman.com> wrote:
> > >> > > > > > >> > >> > >
> > >> > > > > > >> > >> > >> OK - Also, is CURATOR-161 complete? The issue
> is
> > >> still
> > >> > > > open
> > >> > > > > in
> > >> > > > > > >> > Jira.
> > >> > > > > > >> > >> > >>
> > >> > > > > > >> > >> > >>
> > >> > > > > > >> > >> > >>
> > >> > > > > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron
> > >> McKenzie (
> > >> > > > > > >> > >> > >> mckenzie.cam@gmail.com) wrote:
> > >> > > > > > >> > >> > >>
> > >> > > > > > >> > >> > >> Yes, I merged it in last week some time.
> > >> > > > > > >> > >> > >>
> > >> > > > > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan
> > Zimmerman <
> > >> > > > > > >> > >> > >> jordan@jordanzimmerman.com> wrote:
> > >> > > > > > >> > >> > >>
> > >> > > > > > >> > >> > >> > Scott, did CURATOR-217 get merged into the
> new
> > >> > > > > CURATOR-3.0?
> > >> > > > > > >> > >> > >> >
> > >> > > > > > >> > >> > >> > -Jordan
> > >> > > > > > >> > >> > >> >
> > >> > > > > > >> > >> > >> >
> > >> > > > > > >> > >> > >> >
> > >> > > > > > >> > >> > >>
> > >> > > > > > >> > >> > >
> > >> > > > > > >> > >> > >
> > >> > > > > > >> > >> >
> > >> > > > > > >> > >> >
> > >> > > > > > >> > >>
> > >> > > > > > >> > >
> > >> > > > > > >> > >
> > >> > > > > > >> >
> > >> > > > > > >>
> > >> > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: CURATOR-217?
Posted by Mike Drob <ma...@cloudera.com>.
Is this on 3.0 or master? Can you create a JIRA with some log output?
On Tue, Aug 25, 2015 at 6:15 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Is anyone seeing fairly consistent failure of the
>
> TestBoundedDistributedQueue.testMulti:184
>
> test? When I run from inside eclipse in isolation it seems ok, but running
> a 'mvn test' seems to fail on this test with some consistency. The changes
> for CURATOR-167 certainly haven't caused this to happen.
> cheers
>
> On Wed, Aug 26, 2015 at 7:45 AM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
> > Thanks Scott,
> > I will merge into master.
> > cheers
> >
> > On Wed, Aug 26, 2015 at 1:00 AM, Scott Blum <dr...@gmail.com>
> wrote:
> >
> >> Yep, that looks perfect. Is CURATOR-167 done? If so, we can just
> >> fast-foward merge it into master now.
> >>
> >> On Tue, Aug 25, 2015 at 12:11 AM, Cameron McKenzie <
> >> mckenzie.cam@gmail.com>
> >> wrote:
> >>
> >> > Thanks Scott,
> >> > Done, would you mind checking the origin/CURATOR-167 to make sure
> that I
> >> > haven't done anything wrong! I have done a git pull on a different
> >> machine
> >> > and it seems to be ok.
> >> > cheers
> >> >
> >> > On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum <dr...@gmail.com>
> >> wrote:
> >> >
> >> > > You just force push your branch.
> >> > >
> >> > > If it's your feature branch, and you know you have it in a good
> state
> >> > > locally, you can just force push the remote branch into the same
> >> state.
> >> > >
> >> > > You'd never want to do that to master, a release branch, or someone
> >> > else's
> >> > > branch.
> >> > > On Aug 24, 2015 11:15 PM, "Cameron McKenzie" <
> mckenzie.cam@gmail.com>
> >> > > wrote:
> >> > >
> >> > > > Thanks Mike,
> >> > > > That was a good description. The CURATOR-167 branch is definitely
> >> there
> >> > > as
> >> > > > it's been a pull request for the last few months. So, I'll await
> >> your
> >> > > > thoughts in the morning. Alternatively, I can just merge master
> >> instead
> >> > > of
> >> > > > rebasing it.
> >> > > >
> >> > > > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <ma...@cloudera.com>
> >> > wrote:
> >> > > >
> >> > > > > Yea, that's the big downside with rebasing, is that remotes
> don't
> >> > > exactly
> >> > > > > keep up with the history. I'm going to try to explain this as
> best
> >> > as I
> >> > > > > can, but usually I point people towards this excellent "Git for
> >> Ages
> >> > 4
> >> > > > and
> >> > > > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he
> talks
> >> > about
> >> > > > > rebases at the very very end, around the 1:30 mark.
> >> > > > >
> >> > > > > Essentially, your current version of the branch does not have
> the
> >> > > remote
> >> > > > > version of the as an ancestor. Which is correct, when you did
> the
> >> > > rebase,
> >> > > > > you wrote a new commit lineage.
> >> > > > >
> >> > > > > I didn't realize that there was already a CURATOR-167 branch
> >> pushed
> >> > to
> >> > > > the
> >> > > > > repo when I gave you those steps. I'll have to look at what's
> >> going
> >> > on
> >> > > > with
> >> > > > > a fresh set of eyes in the morning.
> >> > > > >
> >> > > > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <
> >> > > > mckenzie.cam@gmail.com>
> >> > > > > wrote:
> >> > > > >
> >> > > > > > I just tried this and obviously I'm doing something wrong.
> >> > > > > >
> >> > > > > > git checkout CURATOR-167
> >> > > > > > git pull
> >> > > > > > git rebase -i origin/master
> >> > > > > >
> >> > > > > > #This gives me a dialog with one commit with pick
> >> > > > > > Save and exit
> >> > > > > > #This gives a merge conflict and leaves me in a detached head
> >> state
> >> > > (I
> >> > > > > > presume this is ok).
> >> > > > > > Fix up the merge conflict
> >> > > > > > git rebase --continue
> >> > > > > > #This gives me a dialog to commit the changes
> >> > > > > > Save and exit
> >> > > > > > #Everything seems fine at this point. Builds ok, tests run ok.
> >> > > > > >
> >> > > > > > git push
> >> > > > > >
> >> > > > > > ! [rejected] CURATOR-167 -> CURATOR-167
> >> (non-fast-forward)
> >> > > > > > error: failed to push some refs to '
> >> > > > > > https://git-wip-us.apache.org/repos/asf/curator.git'
> >> > > > > > hint: Updates were rejected because the tip of your current
> >> branch
> >> > is
> >> > > > > > behind
> >> > > > > > hint: its remote counterpart. Integrate the remote changes
> (e.g.
> >> > > > > > hint: 'git pull ...') before pushing again.
> >> > > > > > hint: See the 'Note about fast-forwards' in 'git push --help'
> >> for
> >> > > > > details.
> >> > > > > >
> >> > > > > > There have been no changes on the branch since I did the pull
> >> > before
> >> > > > the
> >> > > > > > rebase.
> >> > > > > >
> >> > > > > > Any ideas?
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <
> >> > > > > mckenzie.cam@gmail.com>
> >> > > > > > wrote:
> >> > > > > >
> >> > > > > > > Thanks Mike,
> >> > > > > > > Will give it a spin today some time.
> >> > > > > > > cheers
> >> > > > > > >
> >> > > > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <
> >> madrob@cloudera.com>
> >> > > > > wrote:
> >> > > > > > >
> >> > > > > > >> if you're going to tray that, here's what you want to do
> >> > (assuming
> >> > > > > > command
> >> > > > > > >> line)
> >> > > > > > >>
> >> > > > > > >> git checkout CURATOR-167 # start with the branch that you
> are
> >> > > > changing
> >> > > > > > >> git rebase -i master # rebase the current branch on top of
> >> the
> >> > > given
> >> > > > > > >> branch
> >> > > > > > >>
> >> > > > > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
> >> > > > > > mckenzie.cam@gmail.com
> >> > > > > > >> >
> >> > > > > > >> wrote:
> >> > > > > > >>
> >> > > > > > >> > Scott,
> >> > > > > > >> > I've been using a similar approach to Jordan given that's
> >> what
> >> > > I'm
> >> > > > > > used
> >> > > > > > >> to,
> >> > > > > > >> > but I'm happy to try your approach. I'm going to try and
> >> fix
> >> > up
> >> > > > > > >> CURATOR-167
> >> > > > > > >> > as it will no longer cleanly merge (it's been sitting
> >> there a
> >> > > > > while).
> >> > > > > > >> So, I
> >> > > > > > >> > should rebase master into the CURATOR-167 branch?
> >> > > > > > >> > cheers
> >> > > > > > >> >
> >> > > > > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <
> >> > > > dragonsinth@apache.org
> >> > > > > >
> >> > > > > > >> > wrote:
> >> > > > > > >> >
> >> > > > > > >> > > LOL! So sorry to hear that. Yeah, it's definitely
> >> possible
> >> > > to
> >> > > > > mess
> >> > > > > > >> > > things up badly. If I'm doing something particularly
> >> risky,
> >> > > > I'll
> >> > > > > > just
> >> > > > > > >> > "git
> >> > > > > > >> > > branch original" before I start, so as to leave a
> branch
> >> > > pointer
> >> > > > > at
> >> > > > > > my
> >> > > > > > >> > > start point as a safe recovery if it goes south. I
> also
> >> use
> >> > > > gitk
> >> > > > > to
> >> > > > > > >> > > visualize sometimes.
> >> > > > > > >> > >
> >> > > > > > >> > > Another major selling point for rebase (-i) is that
> it's
> >> > > > *really*
> >> > > > > > >> hard to
> >> > > > > > >> > > merge the wrong branch. If the list of commits that
> >> comes
> >> > up
> >> > > > > > doesn't
> >> > > > > > >> > look
> >> > > > > > >> > > basically correct, you probably did something wrong--
> >> trying
> >> > > to
> >> > > > > > rebase
> >> > > > > > >> > onto
> >> > > > > > >> > > the wrong branch will give you tons of commits, most of
> >> > which
> >> > > > > aren't
> >> > > > > > >> > yours.
> >> > > > > > >> > >
> >> > > > > > >> > > I think what you've been doing is fine, it's definitely
> >> the
> >> > > > right
> >> > > > > > >> > approach
> >> > > > > > >> > > if you're doing a merge strategy! I've just ended up
> >> > > > gravitating
> >> > > > > > to a
> >> > > > > > >> > > rebase strategy over the years for the reasons I've
> >> > mentioned.
> >> > > > > > >> > >
> >> > > > > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> >> > > > > > >> > > jordan@jordanzimmerman.com> wrote:
> >> > > > > > >> > >
> >> > > > > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up
> several
> >> > > > projects
> >> > > > > > >> with
> >> > > > > > >> > it
> >> > > > > > >> > >> so I can’t even type the letters without breaking
> into a
> >> > > sweat.
> >> > > > > > "git
> >> > > > > > >> > rebase
> >> > > > > > >> > >> -i” is a lot safer, though. Here’s what I’ve been
> doing
> >> -
> >> > let
> >> > > > me
> >> > > > > > >> know if
> >> > > > > > >> > >> it’s OK. For branches that are off of CURATOR-3.0, I
> >> never
> >> > > > merge
> >> > > > > > >> > master. I
> >> > > > > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In
> >> fact,
> >> > > > should
> >> > > > > we
> >> > > > > > >> > have a
> >> > > > > > >> > >> branch naming scheme to enforce this?
> >> > > > > > >> > >>
> >> > > > > > >> > >> -Jordan
> >> > > > > > >> > >>
> >> > > > > > >> > >>
> >> > > > > > >> > >>
> >> > > > > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
> >> > > > > > >> dragonsinth@apache.org)
> >> > > > > > >> > >> wrote:
> >> > > > > > >> > >>
> >> > > > > > >> > >> Correct. When I say "main" branch vs. "feature"
> branch I
> >> > just
> >> > > > > mean
> >> > > > > > >> the
> >> > > > > > >> > >> stable branch everyone is working against (3.0 or
> >> master)
> >> > > vs. a
> >> > > > > > >> feature
> >> > > > > > >> > >> branch where you're actively working.
> >> > > > > > >> > >>
> >> > > > > > >> > >> You'll get to a point in development where you'll
> think
> >> > "Hey,
> >> > > > > there
> >> > > > > > >> are
> >> > > > > > >> > >> changes on the main branch I'm working against that I
> >> > really
> >> > > > need
> >> > > > > > to
> >> > > > > > >> > pull
> >> > > > > > >> > >> into my feature branch." At that point (particularly
> if
> >> you
> >> > > > have
> >> > > > > an
> >> > > > > > >> svn
> >> > > > > > >> > >> background) you'll be tempted to merge the main branch
> >> into
> >> > > > your
> >> > > > > > >> feature
> >> > > > > > >> > >> branch. I would suggest not doing that, as it makes
> the
> >> > > history
> >> > > > > > very
> >> > > > > > >> > muddy
> >> > > > > > >> > >> to follow. Instead, my workflow is usually more like
> >> this:
> >> > > > > > >> > >>
> >> > > > > > >> > >> Suppose I'm working on CURATOR-218. It was originally
> >> > > branched
> >> > > > > off
> >> > > > > > >> 3.0,
> >> > > > > > >> > >> and I want to pull in new changes.
> >> > > > > > >> > >>
> >> > > > > > >> > >> git remote update
> >> > > > > > >> > >> git rebase -i origin/CURATOR-3.0
> >> > > > > > >> > >>
> >> > > > > > >> > >> This pulls up an editor that gives me the list of
> >> commits
> >> > to
> >> > > > > > rebase.
> >> > > > > > >> I
> >> > > > > > >> > >> would typically exit out of the editor to at this
> point
> >> to
> >> > > > accept
> >> > > > > > the
> >> > > > > > >> > >> commit list, but if I'm so inclined, I'll do things
> like
> >> > > > reorder
> >> > > > > > the
> >> > > > > > >> > list,
> >> > > > > > >> > >> or squash commits like like "wip" or "minor reformat"
> >> into
> >> > a
> >> > > > more
> >> > > > > > >> > curated
> >> > > > > > >> > >> set of logical commits.
> >> > > > > > >> > >>
> >> > > > > > >> > >> Once you exit the editor, git goes through and applies
> >> each
> >> > > > > commit,
> >> > > > > > >> one
> >> > > > > > >> > at
> >> > > > > > >> > >> a time, to the head of the target branch. It's like
> >> picking
> >> > > up
> >> > > > > your
> >> > > > > > >> > commit
> >> > > > > > >> > >> chain and dumping it at the end of the target branch,
> >> as if
> >> > > all
> >> > > > > > your
> >> > > > > > >> > work
> >> > > > > > >> > >> had been done against what's now the head of that
> >> branch.
> >> > > > You'll
> >> > > > > > may
> >> > > > > > >> > have
> >> > > > > > >> > >> to fix conflicts along the way, but usually not much
> >> more
> >> > > than
> >> > > > if
> >> > > > > > you
> >> > > > > > >> > did
> >> > > > > > >> > >> it as a merge.
> >> > > > > > >> > >>
> >> > > > > > >> > >> I'd encourage us to try this out a couple times and
> get
> >> a
> >> > > feel
> >> > > > > for
> >> > > > > > >> the
> >> > > > > > >> > >> rebase flow. It's a little more to get your head
> around
> >> at
> >> > > > first,
> >> > > > > > but
> >> > > > > > >> > the
> >> > > > > > >> > >> upside is you end up with really easy to follow commit
> >> > > > histories,
> >> > > > > > >> which
> >> > > > > > >> > >> makes it way easier to untangle problems later if they
> >> crop
> >> > > up.
> >> > > > > > >> > >>
> >> > > > > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> >> > > > > > >> > >> jordan@jordanzimmerman.com> wrote:
> >> > > > > > >> > >>
> >> > > > > > >> > >> > Can you explain this in detail? For me, I have some
> >> > > features
> >> > > > > that
> >> > > > > > >> are
> >> > > > > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of
> >> > > master.
> >> > > > > The
> >> > > > > > >> true
> >> > > > > > >> > >> > “master” is Curator 2.x only, right?
> >> > > > > > >> > >> >
> >> > > > > > >> > >> > -Jordan
> >> > > > > > >> > >> >
> >> > > > > > >> > >> >
> >> > > > > > >> > >> >
> >> > > > > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
> >> > > > > > >> dragonsinth@apache.org
> >> > > > > > >> > )
> >> > > > > > >> > >> > wrote:
> >> > > > > > >> > >> >
> >> > > > > > >> > >> > BTW: I noticed a couple of new commits
> >> > > > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> >> > > > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where
> 3.0
> >> is
> >> > > > > getting
> >> > > > > > >> > merged
> >> > > > > > >> > >> > into feature branches. Almost every project I've
> been
> >> on
> >> > we
> >> > > > > don't
> >> > > > > > >> tend
> >> > > > > > >> > >> to
> >> > > > > > >> > >> > do that as it leads to confusing history (this isn't
> >> just
> >> > > > > > >> aesthetic,
> >> > > > > > >> > it
> >> > > > > > >> > >> > can
> >> > > > > > >> > >> > get harder for tooling to figure out what happened).
> >> If I
> >> > > > want
> >> > > > > to
> >> > > > > > >> pull
> >> > > > > > >> > >> > changes from the main branch into my feature
> branch, I
> >> > > would
> >> > > > > > >> typically
> >> > > > > > >> > >> > *rebase* my feature branch against the main branch.
> >> > > > > > >> > >> >
> >> > > > > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
> >> > > > > > >> dragonsinth@apache.org>
> >> > > > > > >> > >> > wrote:
> >> > > > > > >> > >> >
> >> > > > > > >> > >> > > Yeah, 217 & 161 were the first two big things in
> >> 3.0.
> >> > > > > > >> > >> > >
> >> > > > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman
> <
> >> > > > > > >> > >> > > jordan@jordanzimmerman.com> wrote:
> >> > > > > > >> > >> > >
> >> > > > > > >> > >> > >> OK - Also, is CURATOR-161 complete? The issue is
> >> still
> >> > > > open
> >> > > > > in
> >> > > > > > >> > Jira.
> >> > > > > > >> > >> > >>
> >> > > > > > >> > >> > >>
> >> > > > > > >> > >> > >>
> >> > > > > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron
> >> McKenzie (
> >> > > > > > >> > >> > >> mckenzie.cam@gmail.com) wrote:
> >> > > > > > >> > >> > >>
> >> > > > > > >> > >> > >> Yes, I merged it in last week some time.
> >> > > > > > >> > >> > >>
> >> > > > > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan
> Zimmerman <
> >> > > > > > >> > >> > >> jordan@jordanzimmerman.com> wrote:
> >> > > > > > >> > >> > >>
> >> > > > > > >> > >> > >> > Scott, did CURATOR-217 get merged into the new
> >> > > > > CURATOR-3.0?
> >> > > > > > >> > >> > >> >
> >> > > > > > >> > >> > >> > -Jordan
> >> > > > > > >> > >> > >> >
> >> > > > > > >> > >> > >> >
> >> > > > > > >> > >> > >> >
> >> > > > > > >> > >> > >>
> >> > > > > > >> > >> > >
> >> > > > > > >> > >> > >
> >> > > > > > >> > >> >
> >> > > > > > >> > >> >
> >> > > > > > >> > >>
> >> > > > > > >> > >
> >> > > > > > >> > >
> >> > > > > > >> >
> >> > > > > > >>
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
Is anyone seeing fairly consistent failure of the
TestBoundedDistributedQueue.testMulti:184
test? When I run from inside eclipse in isolation it seems ok, but running
a 'mvn test' seems to fail on this test with some consistency. The changes
for CURATOR-167 certainly haven't caused this to happen.
cheers
On Wed, Aug 26, 2015 at 7:45 AM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Thanks Scott,
> I will merge into master.
> cheers
>
> On Wed, Aug 26, 2015 at 1:00 AM, Scott Blum <dr...@gmail.com> wrote:
>
>> Yep, that looks perfect. Is CURATOR-167 done? If so, we can just
>> fast-foward merge it into master now.
>>
>> On Tue, Aug 25, 2015 at 12:11 AM, Cameron McKenzie <
>> mckenzie.cam@gmail.com>
>> wrote:
>>
>> > Thanks Scott,
>> > Done, would you mind checking the origin/CURATOR-167 to make sure that I
>> > haven't done anything wrong! I have done a git pull on a different
>> machine
>> > and it seems to be ok.
>> > cheers
>> >
>> > On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum <dr...@gmail.com>
>> wrote:
>> >
>> > > You just force push your branch.
>> > >
>> > > If it's your feature branch, and you know you have it in a good state
>> > > locally, you can just force push the remote branch into the same
>> state.
>> > >
>> > > You'd never want to do that to master, a release branch, or someone
>> > else's
>> > > branch.
>> > > On Aug 24, 2015 11:15 PM, "Cameron McKenzie" <mc...@gmail.com>
>> > > wrote:
>> > >
>> > > > Thanks Mike,
>> > > > That was a good description. The CURATOR-167 branch is definitely
>> there
>> > > as
>> > > > it's been a pull request for the last few months. So, I'll await
>> your
>> > > > thoughts in the morning. Alternatively, I can just merge master
>> instead
>> > > of
>> > > > rebasing it.
>> > > >
>> > > > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <ma...@cloudera.com>
>> > wrote:
>> > > >
>> > > > > Yea, that's the big downside with rebasing, is that remotes don't
>> > > exactly
>> > > > > keep up with the history. I'm going to try to explain this as best
>> > as I
>> > > > > can, but usually I point people towards this excellent "Git for
>> Ages
>> > 4
>> > > > and
>> > > > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he talks
>> > about
>> > > > > rebases at the very very end, around the 1:30 mark.
>> > > > >
>> > > > > Essentially, your current version of the branch does not have the
>> > > remote
>> > > > > version of the as an ancestor. Which is correct, when you did the
>> > > rebase,
>> > > > > you wrote a new commit lineage.
>> > > > >
>> > > > > I didn't realize that there was already a CURATOR-167 branch
>> pushed
>> > to
>> > > > the
>> > > > > repo when I gave you those steps. I'll have to look at what's
>> going
>> > on
>> > > > with
>> > > > > a fresh set of eyes in the morning.
>> > > > >
>> > > > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <
>> > > > mckenzie.cam@gmail.com>
>> > > > > wrote:
>> > > > >
>> > > > > > I just tried this and obviously I'm doing something wrong.
>> > > > > >
>> > > > > > git checkout CURATOR-167
>> > > > > > git pull
>> > > > > > git rebase -i origin/master
>> > > > > >
>> > > > > > #This gives me a dialog with one commit with pick
>> > > > > > Save and exit
>> > > > > > #This gives a merge conflict and leaves me in a detached head
>> state
>> > > (I
>> > > > > > presume this is ok).
>> > > > > > Fix up the merge conflict
>> > > > > > git rebase --continue
>> > > > > > #This gives me a dialog to commit the changes
>> > > > > > Save and exit
>> > > > > > #Everything seems fine at this point. Builds ok, tests run ok.
>> > > > > >
>> > > > > > git push
>> > > > > >
>> > > > > > ! [rejected] CURATOR-167 -> CURATOR-167
>> (non-fast-forward)
>> > > > > > error: failed to push some refs to '
>> > > > > > https://git-wip-us.apache.org/repos/asf/curator.git'
>> > > > > > hint: Updates were rejected because the tip of your current
>> branch
>> > is
>> > > > > > behind
>> > > > > > hint: its remote counterpart. Integrate the remote changes (e.g.
>> > > > > > hint: 'git pull ...') before pushing again.
>> > > > > > hint: See the 'Note about fast-forwards' in 'git push --help'
>> for
>> > > > > details.
>> > > > > >
>> > > > > > There have been no changes on the branch since I did the pull
>> > before
>> > > > the
>> > > > > > rebase.
>> > > > > >
>> > > > > > Any ideas?
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <
>> > > > > mckenzie.cam@gmail.com>
>> > > > > > wrote:
>> > > > > >
>> > > > > > > Thanks Mike,
>> > > > > > > Will give it a spin today some time.
>> > > > > > > cheers
>> > > > > > >
>> > > > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <
>> madrob@cloudera.com>
>> > > > > wrote:
>> > > > > > >
>> > > > > > >> if you're going to tray that, here's what you want to do
>> > (assuming
>> > > > > > command
>> > > > > > >> line)
>> > > > > > >>
>> > > > > > >> git checkout CURATOR-167 # start with the branch that you are
>> > > > changing
>> > > > > > >> git rebase -i master # rebase the current branch on top of
>> the
>> > > given
>> > > > > > >> branch
>> > > > > > >>
>> > > > > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
>> > > > > > mckenzie.cam@gmail.com
>> > > > > > >> >
>> > > > > > >> wrote:
>> > > > > > >>
>> > > > > > >> > Scott,
>> > > > > > >> > I've been using a similar approach to Jordan given that's
>> what
>> > > I'm
>> > > > > > used
>> > > > > > >> to,
>> > > > > > >> > but I'm happy to try your approach. I'm going to try and
>> fix
>> > up
>> > > > > > >> CURATOR-167
>> > > > > > >> > as it will no longer cleanly merge (it's been sitting
>> there a
>> > > > > while).
>> > > > > > >> So, I
>> > > > > > >> > should rebase master into the CURATOR-167 branch?
>> > > > > > >> > cheers
>> > > > > > >> >
>> > > > > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <
>> > > > dragonsinth@apache.org
>> > > > > >
>> > > > > > >> > wrote:
>> > > > > > >> >
>> > > > > > >> > > LOL! So sorry to hear that. Yeah, it's definitely
>> possible
>> > > to
>> > > > > mess
>> > > > > > >> > > things up badly. If I'm doing something particularly
>> risky,
>> > > > I'll
>> > > > > > just
>> > > > > > >> > "git
>> > > > > > >> > > branch original" before I start, so as to leave a branch
>> > > pointer
>> > > > > at
>> > > > > > my
>> > > > > > >> > > start point as a safe recovery if it goes south. I also
>> use
>> > > > gitk
>> > > > > to
>> > > > > > >> > > visualize sometimes.
>> > > > > > >> > >
>> > > > > > >> > > Another major selling point for rebase (-i) is that it's
>> > > > *really*
>> > > > > > >> hard to
>> > > > > > >> > > merge the wrong branch. If the list of commits that
>> comes
>> > up
>> > > > > > doesn't
>> > > > > > >> > look
>> > > > > > >> > > basically correct, you probably did something wrong--
>> trying
>> > > to
>> > > > > > rebase
>> > > > > > >> > onto
>> > > > > > >> > > the wrong branch will give you tons of commits, most of
>> > which
>> > > > > aren't
>> > > > > > >> > yours.
>> > > > > > >> > >
>> > > > > > >> > > I think what you've been doing is fine, it's definitely
>> the
>> > > > right
>> > > > > > >> > approach
>> > > > > > >> > > if you're doing a merge strategy! I've just ended up
>> > > > gravitating
>> > > > > > to a
>> > > > > > >> > > rebase strategy over the years for the reasons I've
>> > mentioned.
>> > > > > > >> > >
>> > > > > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
>> > > > > > >> > > jordan@jordanzimmerman.com> wrote:
>> > > > > > >> > >
>> > > > > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up several
>> > > > projects
>> > > > > > >> with
>> > > > > > >> > it
>> > > > > > >> > >> so I can’t even type the letters without breaking into a
>> > > sweat.
>> > > > > > "git
>> > > > > > >> > rebase
>> > > > > > >> > >> -i” is a lot safer, though. Here’s what I’ve been doing
>> -
>> > let
>> > > > me
>> > > > > > >> know if
>> > > > > > >> > >> it’s OK. For branches that are off of CURATOR-3.0, I
>> never
>> > > > merge
>> > > > > > >> > master. I
>> > > > > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In
>> fact,
>> > > > should
>> > > > > we
>> > > > > > >> > have a
>> > > > > > >> > >> branch naming scheme to enforce this?
>> > > > > > >> > >>
>> > > > > > >> > >> -Jordan
>> > > > > > >> > >>
>> > > > > > >> > >>
>> > > > > > >> > >>
>> > > > > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
>> > > > > > >> dragonsinth@apache.org)
>> > > > > > >> > >> wrote:
>> > > > > > >> > >>
>> > > > > > >> > >> Correct. When I say "main" branch vs. "feature" branch I
>> > just
>> > > > > mean
>> > > > > > >> the
>> > > > > > >> > >> stable branch everyone is working against (3.0 or
>> master)
>> > > vs. a
>> > > > > > >> feature
>> > > > > > >> > >> branch where you're actively working.
>> > > > > > >> > >>
>> > > > > > >> > >> You'll get to a point in development where you'll think
>> > "Hey,
>> > > > > there
>> > > > > > >> are
>> > > > > > >> > >> changes on the main branch I'm working against that I
>> > really
>> > > > need
>> > > > > > to
>> > > > > > >> > pull
>> > > > > > >> > >> into my feature branch." At that point (particularly if
>> you
>> > > > have
>> > > > > an
>> > > > > > >> svn
>> > > > > > >> > >> background) you'll be tempted to merge the main branch
>> into
>> > > > your
>> > > > > > >> feature
>> > > > > > >> > >> branch. I would suggest not doing that, as it makes the
>> > > history
>> > > > > > very
>> > > > > > >> > muddy
>> > > > > > >> > >> to follow. Instead, my workflow is usually more like
>> this:
>> > > > > > >> > >>
>> > > > > > >> > >> Suppose I'm working on CURATOR-218. It was originally
>> > > branched
>> > > > > off
>> > > > > > >> 3.0,
>> > > > > > >> > >> and I want to pull in new changes.
>> > > > > > >> > >>
>> > > > > > >> > >> git remote update
>> > > > > > >> > >> git rebase -i origin/CURATOR-3.0
>> > > > > > >> > >>
>> > > > > > >> > >> This pulls up an editor that gives me the list of
>> commits
>> > to
>> > > > > > rebase.
>> > > > > > >> I
>> > > > > > >> > >> would typically exit out of the editor to at this point
>> to
>> > > > accept
>> > > > > > the
>> > > > > > >> > >> commit list, but if I'm so inclined, I'll do things like
>> > > > reorder
>> > > > > > the
>> > > > > > >> > list,
>> > > > > > >> > >> or squash commits like like "wip" or "minor reformat"
>> into
>> > a
>> > > > more
>> > > > > > >> > curated
>> > > > > > >> > >> set of logical commits.
>> > > > > > >> > >>
>> > > > > > >> > >> Once you exit the editor, git goes through and applies
>> each
>> > > > > commit,
>> > > > > > >> one
>> > > > > > >> > at
>> > > > > > >> > >> a time, to the head of the target branch. It's like
>> picking
>> > > up
>> > > > > your
>> > > > > > >> > commit
>> > > > > > >> > >> chain and dumping it at the end of the target branch,
>> as if
>> > > all
>> > > > > > your
>> > > > > > >> > work
>> > > > > > >> > >> had been done against what's now the head of that
>> branch.
>> > > > You'll
>> > > > > > may
>> > > > > > >> > have
>> > > > > > >> > >> to fix conflicts along the way, but usually not much
>> more
>> > > than
>> > > > if
>> > > > > > you
>> > > > > > >> > did
>> > > > > > >> > >> it as a merge.
>> > > > > > >> > >>
>> > > > > > >> > >> I'd encourage us to try this out a couple times and get
>> a
>> > > feel
>> > > > > for
>> > > > > > >> the
>> > > > > > >> > >> rebase flow. It's a little more to get your head around
>> at
>> > > > first,
>> > > > > > but
>> > > > > > >> > the
>> > > > > > >> > >> upside is you end up with really easy to follow commit
>> > > > histories,
>> > > > > > >> which
>> > > > > > >> > >> makes it way easier to untangle problems later if they
>> crop
>> > > up.
>> > > > > > >> > >>
>> > > > > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
>> > > > > > >> > >> jordan@jordanzimmerman.com> wrote:
>> > > > > > >> > >>
>> > > > > > >> > >> > Can you explain this in detail? For me, I have some
>> > > features
>> > > > > that
>> > > > > > >> are
>> > > > > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of
>> > > master.
>> > > > > The
>> > > > > > >> true
>> > > > > > >> > >> > “master” is Curator 2.x only, right?
>> > > > > > >> > >> >
>> > > > > > >> > >> > -Jordan
>> > > > > > >> > >> >
>> > > > > > >> > >> >
>> > > > > > >> > >> >
>> > > > > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
>> > > > > > >> dragonsinth@apache.org
>> > > > > > >> > )
>> > > > > > >> > >> > wrote:
>> > > > > > >> > >> >
>> > > > > > >> > >> > BTW: I noticed a couple of new commits
>> > > > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
>> > > > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0
>> is
>> > > > > getting
>> > > > > > >> > merged
>> > > > > > >> > >> > into feature branches. Almost every project I've been
>> on
>> > we
>> > > > > don't
>> > > > > > >> tend
>> > > > > > >> > >> to
>> > > > > > >> > >> > do that as it leads to confusing history (this isn't
>> just
>> > > > > > >> aesthetic,
>> > > > > > >> > it
>> > > > > > >> > >> > can
>> > > > > > >> > >> > get harder for tooling to figure out what happened).
>> If I
>> > > > want
>> > > > > to
>> > > > > > >> pull
>> > > > > > >> > >> > changes from the main branch into my feature branch, I
>> > > would
>> > > > > > >> typically
>> > > > > > >> > >> > *rebase* my feature branch against the main branch.
>> > > > > > >> > >> >
>> > > > > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
>> > > > > > >> dragonsinth@apache.org>
>> > > > > > >> > >> > wrote:
>> > > > > > >> > >> >
>> > > > > > >> > >> > > Yeah, 217 & 161 were the first two big things in
>> 3.0.
>> > > > > > >> > >> > >
>> > > > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
>> > > > > > >> > >> > > jordan@jordanzimmerman.com> wrote:
>> > > > > > >> > >> > >
>> > > > > > >> > >> > >> OK - Also, is CURATOR-161 complete? The issue is
>> still
>> > > > open
>> > > > > in
>> > > > > > >> > Jira.
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron
>> McKenzie (
>> > > > > > >> > >> > >> mckenzie.cam@gmail.com) wrote:
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >> Yes, I merged it in last week some time.
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
>> > > > > > >> > >> > >> jordan@jordanzimmerman.com> wrote:
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >> > Scott, did CURATOR-217 get merged into the new
>> > > > > CURATOR-3.0?
>> > > > > > >> > >> > >> >
>> > > > > > >> > >> > >> > -Jordan
>> > > > > > >> > >> > >> >
>> > > > > > >> > >> > >> >
>> > > > > > >> > >> > >> >
>> > > > > > >> > >> > >>
>> > > > > > >> > >> > >
>> > > > > > >> > >> > >
>> > > > > > >> > >> >
>> > > > > > >> > >> >
>> > > > > > >> > >>
>> > > > > > >> > >
>> > > > > > >> > >
>> > > > > > >> >
>> > > > > > >>
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
>
>
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
Thanks Scott,
I will merge into master.
cheers
On Wed, Aug 26, 2015 at 1:00 AM, Scott Blum <dr...@gmail.com> wrote:
> Yep, that looks perfect. Is CURATOR-167 done? If so, we can just
> fast-foward merge it into master now.
>
> On Tue, Aug 25, 2015 at 12:11 AM, Cameron McKenzie <mckenzie.cam@gmail.com
> >
> wrote:
>
> > Thanks Scott,
> > Done, would you mind checking the origin/CURATOR-167 to make sure that I
> > haven't done anything wrong! I have done a git pull on a different
> machine
> > and it seems to be ok.
> > cheers
> >
> > On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum <dr...@gmail.com>
> wrote:
> >
> > > You just force push your branch.
> > >
> > > If it's your feature branch, and you know you have it in a good state
> > > locally, you can just force push the remote branch into the same state.
> > >
> > > You'd never want to do that to master, a release branch, or someone
> > else's
> > > branch.
> > > On Aug 24, 2015 11:15 PM, "Cameron McKenzie" <mc...@gmail.com>
> > > wrote:
> > >
> > > > Thanks Mike,
> > > > That was a good description. The CURATOR-167 branch is definitely
> there
> > > as
> > > > it's been a pull request for the last few months. So, I'll await your
> > > > thoughts in the morning. Alternatively, I can just merge master
> instead
> > > of
> > > > rebasing it.
> > > >
> > > > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <ma...@cloudera.com>
> > wrote:
> > > >
> > > > > Yea, that's the big downside with rebasing, is that remotes don't
> > > exactly
> > > > > keep up with the history. I'm going to try to explain this as best
> > as I
> > > > > can, but usually I point people towards this excellent "Git for
> Ages
> > 4
> > > > and
> > > > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he talks
> > about
> > > > > rebases at the very very end, around the 1:30 mark.
> > > > >
> > > > > Essentially, your current version of the branch does not have the
> > > remote
> > > > > version of the as an ancestor. Which is correct, when you did the
> > > rebase,
> > > > > you wrote a new commit lineage.
> > > > >
> > > > > I didn't realize that there was already a CURATOR-167 branch pushed
> > to
> > > > the
> > > > > repo when I gave you those steps. I'll have to look at what's going
> > on
> > > > with
> > > > > a fresh set of eyes in the morning.
> > > > >
> > > > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <
> > > > mckenzie.cam@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I just tried this and obviously I'm doing something wrong.
> > > > > >
> > > > > > git checkout CURATOR-167
> > > > > > git pull
> > > > > > git rebase -i origin/master
> > > > > >
> > > > > > #This gives me a dialog with one commit with pick
> > > > > > Save and exit
> > > > > > #This gives a merge conflict and leaves me in a detached head
> state
> > > (I
> > > > > > presume this is ok).
> > > > > > Fix up the merge conflict
> > > > > > git rebase --continue
> > > > > > #This gives me a dialog to commit the changes
> > > > > > Save and exit
> > > > > > #Everything seems fine at this point. Builds ok, tests run ok.
> > > > > >
> > > > > > git push
> > > > > >
> > > > > > ! [rejected] CURATOR-167 -> CURATOR-167
> (non-fast-forward)
> > > > > > error: failed to push some refs to '
> > > > > > https://git-wip-us.apache.org/repos/asf/curator.git'
> > > > > > hint: Updates were rejected because the tip of your current
> branch
> > is
> > > > > > behind
> > > > > > hint: its remote counterpart. Integrate the remote changes (e.g.
> > > > > > hint: 'git pull ...') before pushing again.
> > > > > > hint: See the 'Note about fast-forwards' in 'git push --help' for
> > > > > details.
> > > > > >
> > > > > > There have been no changes on the branch since I did the pull
> > before
> > > > the
> > > > > > rebase.
> > > > > >
> > > > > > Any ideas?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <
> > > > > mckenzie.cam@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Thanks Mike,
> > > > > > > Will give it a spin today some time.
> > > > > > > cheers
> > > > > > >
> > > > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <
> madrob@cloudera.com>
> > > > > wrote:
> > > > > > >
> > > > > > >> if you're going to tray that, here's what you want to do
> > (assuming
> > > > > > command
> > > > > > >> line)
> > > > > > >>
> > > > > > >> git checkout CURATOR-167 # start with the branch that you are
> > > > changing
> > > > > > >> git rebase -i master # rebase the current branch on top of the
> > > given
> > > > > > >> branch
> > > > > > >>
> > > > > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
> > > > > > mckenzie.cam@gmail.com
> > > > > > >> >
> > > > > > >> wrote:
> > > > > > >>
> > > > > > >> > Scott,
> > > > > > >> > I've been using a similar approach to Jordan given that's
> what
> > > I'm
> > > > > > used
> > > > > > >> to,
> > > > > > >> > but I'm happy to try your approach. I'm going to try and fix
> > up
> > > > > > >> CURATOR-167
> > > > > > >> > as it will no longer cleanly merge (it's been sitting there
> a
> > > > > while).
> > > > > > >> So, I
> > > > > > >> > should rebase master into the CURATOR-167 branch?
> > > > > > >> > cheers
> > > > > > >> >
> > > > > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <
> > > > dragonsinth@apache.org
> > > > > >
> > > > > > >> > wrote:
> > > > > > >> >
> > > > > > >> > > LOL! So sorry to hear that. Yeah, it's definitely
> possible
> > > to
> > > > > mess
> > > > > > >> > > things up badly. If I'm doing something particularly
> risky,
> > > > I'll
> > > > > > just
> > > > > > >> > "git
> > > > > > >> > > branch original" before I start, so as to leave a branch
> > > pointer
> > > > > at
> > > > > > my
> > > > > > >> > > start point as a safe recovery if it goes south. I also
> use
> > > > gitk
> > > > > to
> > > > > > >> > > visualize sometimes.
> > > > > > >> > >
> > > > > > >> > > Another major selling point for rebase (-i) is that it's
> > > > *really*
> > > > > > >> hard to
> > > > > > >> > > merge the wrong branch. If the list of commits that comes
> > up
> > > > > > doesn't
> > > > > > >> > look
> > > > > > >> > > basically correct, you probably did something wrong--
> trying
> > > to
> > > > > > rebase
> > > > > > >> > onto
> > > > > > >> > > the wrong branch will give you tons of commits, most of
> > which
> > > > > aren't
> > > > > > >> > yours.
> > > > > > >> > >
> > > > > > >> > > I think what you've been doing is fine, it's definitely
> the
> > > > right
> > > > > > >> > approach
> > > > > > >> > > if you're doing a merge strategy! I've just ended up
> > > > gravitating
> > > > > > to a
> > > > > > >> > > rebase strategy over the years for the reasons I've
> > mentioned.
> > > > > > >> > >
> > > > > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> > > > > > >> > > jordan@jordanzimmerman.com> wrote:
> > > > > > >> > >
> > > > > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up several
> > > > projects
> > > > > > >> with
> > > > > > >> > it
> > > > > > >> > >> so I can’t even type the letters without breaking into a
> > > sweat.
> > > > > > "git
> > > > > > >> > rebase
> > > > > > >> > >> -i” is a lot safer, though. Here’s what I’ve been doing -
> > let
> > > > me
> > > > > > >> know if
> > > > > > >> > >> it’s OK. For branches that are off of CURATOR-3.0, I
> never
> > > > merge
> > > > > > >> > master. I
> > > > > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact,
> > > > should
> > > > > we
> > > > > > >> > have a
> > > > > > >> > >> branch naming scheme to enforce this?
> > > > > > >> > >>
> > > > > > >> > >> -Jordan
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >>
> > > > > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
> > > > > > >> dragonsinth@apache.org)
> > > > > > >> > >> wrote:
> > > > > > >> > >>
> > > > > > >> > >> Correct. When I say "main" branch vs. "feature" branch I
> > just
> > > > > mean
> > > > > > >> the
> > > > > > >> > >> stable branch everyone is working against (3.0 or master)
> > > vs. a
> > > > > > >> feature
> > > > > > >> > >> branch where you're actively working.
> > > > > > >> > >>
> > > > > > >> > >> You'll get to a point in development where you'll think
> > "Hey,
> > > > > there
> > > > > > >> are
> > > > > > >> > >> changes on the main branch I'm working against that I
> > really
> > > > need
> > > > > > to
> > > > > > >> > pull
> > > > > > >> > >> into my feature branch." At that point (particularly if
> you
> > > > have
> > > > > an
> > > > > > >> svn
> > > > > > >> > >> background) you'll be tempted to merge the main branch
> into
> > > > your
> > > > > > >> feature
> > > > > > >> > >> branch. I would suggest not doing that, as it makes the
> > > history
> > > > > > very
> > > > > > >> > muddy
> > > > > > >> > >> to follow. Instead, my workflow is usually more like
> this:
> > > > > > >> > >>
> > > > > > >> > >> Suppose I'm working on CURATOR-218. It was originally
> > > branched
> > > > > off
> > > > > > >> 3.0,
> > > > > > >> > >> and I want to pull in new changes.
> > > > > > >> > >>
> > > > > > >> > >> git remote update
> > > > > > >> > >> git rebase -i origin/CURATOR-3.0
> > > > > > >> > >>
> > > > > > >> > >> This pulls up an editor that gives me the list of commits
> > to
> > > > > > rebase.
> > > > > > >> I
> > > > > > >> > >> would typically exit out of the editor to at this point
> to
> > > > accept
> > > > > > the
> > > > > > >> > >> commit list, but if I'm so inclined, I'll do things like
> > > > reorder
> > > > > > the
> > > > > > >> > list,
> > > > > > >> > >> or squash commits like like "wip" or "minor reformat"
> into
> > a
> > > > more
> > > > > > >> > curated
> > > > > > >> > >> set of logical commits.
> > > > > > >> > >>
> > > > > > >> > >> Once you exit the editor, git goes through and applies
> each
> > > > > commit,
> > > > > > >> one
> > > > > > >> > at
> > > > > > >> > >> a time, to the head of the target branch. It's like
> picking
> > > up
> > > > > your
> > > > > > >> > commit
> > > > > > >> > >> chain and dumping it at the end of the target branch, as
> if
> > > all
> > > > > > your
> > > > > > >> > work
> > > > > > >> > >> had been done against what's now the head of that branch.
> > > > You'll
> > > > > > may
> > > > > > >> > have
> > > > > > >> > >> to fix conflicts along the way, but usually not much more
> > > than
> > > > if
> > > > > > you
> > > > > > >> > did
> > > > > > >> > >> it as a merge.
> > > > > > >> > >>
> > > > > > >> > >> I'd encourage us to try this out a couple times and get a
> > > feel
> > > > > for
> > > > > > >> the
> > > > > > >> > >> rebase flow. It's a little more to get your head around
> at
> > > > first,
> > > > > > but
> > > > > > >> > the
> > > > > > >> > >> upside is you end up with really easy to follow commit
> > > > histories,
> > > > > > >> which
> > > > > > >> > >> makes it way easier to untangle problems later if they
> crop
> > > up.
> > > > > > >> > >>
> > > > > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> > > > > > >> > >> jordan@jordanzimmerman.com> wrote:
> > > > > > >> > >>
> > > > > > >> > >> > Can you explain this in detail? For me, I have some
> > > features
> > > > > that
> > > > > > >> are
> > > > > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of
> > > master.
> > > > > The
> > > > > > >> true
> > > > > > >> > >> > “master” is Curator 2.x only, right?
> > > > > > >> > >> >
> > > > > > >> > >> > -Jordan
> > > > > > >> > >> >
> > > > > > >> > >> >
> > > > > > >> > >> >
> > > > > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
> > > > > > >> dragonsinth@apache.org
> > > > > > >> > )
> > > > > > >> > >> > wrote:
> > > > > > >> > >> >
> > > > > > >> > >> > BTW: I noticed a couple of new commits
> > > > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> > > > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0
> is
> > > > > getting
> > > > > > >> > merged
> > > > > > >> > >> > into feature branches. Almost every project I've been
> on
> > we
> > > > > don't
> > > > > > >> tend
> > > > > > >> > >> to
> > > > > > >> > >> > do that as it leads to confusing history (this isn't
> just
> > > > > > >> aesthetic,
> > > > > > >> > it
> > > > > > >> > >> > can
> > > > > > >> > >> > get harder for tooling to figure out what happened).
> If I
> > > > want
> > > > > to
> > > > > > >> pull
> > > > > > >> > >> > changes from the main branch into my feature branch, I
> > > would
> > > > > > >> typically
> > > > > > >> > >> > *rebase* my feature branch against the main branch.
> > > > > > >> > >> >
> > > > > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
> > > > > > >> dragonsinth@apache.org>
> > > > > > >> > >> > wrote:
> > > > > > >> > >> >
> > > > > > >> > >> > > Yeah, 217 & 161 were the first two big things in 3.0.
> > > > > > >> > >> > >
> > > > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> > > > > > >> > >> > > jordan@jordanzimmerman.com> wrote:
> > > > > > >> > >> > >
> > > > > > >> > >> > >> OK - Also, is CURATOR-161 complete? The issue is
> still
> > > > open
> > > > > in
> > > > > > >> > Jira.
> > > > > > >> > >> > >>
> > > > > > >> > >> > >>
> > > > > > >> > >> > >>
> > > > > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie
> (
> > > > > > >> > >> > >> mckenzie.cam@gmail.com) wrote:
> > > > > > >> > >> > >>
> > > > > > >> > >> > >> Yes, I merged it in last week some time.
> > > > > > >> > >> > >>
> > > > > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> > > > > > >> > >> > >> jordan@jordanzimmerman.com> wrote:
> > > > > > >> > >> > >>
> > > > > > >> > >> > >> > Scott, did CURATOR-217 get merged into the new
> > > > > CURATOR-3.0?
> > > > > > >> > >> > >> >
> > > > > > >> > >> > >> > -Jordan
> > > > > > >> > >> > >> >
> > > > > > >> > >> > >> >
> > > > > > >> > >> > >> >
> > > > > > >> > >> > >>
> > > > > > >> > >> > >
> > > > > > >> > >> > >
> > > > > > >> > >> >
> > > > > > >> > >> >
> > > > > > >> > >>
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> >
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: CURATOR-217?
Posted by Scott Blum <dr...@gmail.com>.
Yep, that looks perfect. Is CURATOR-167 done? If so, we can just
fast-foward merge it into master now.
On Tue, Aug 25, 2015 at 12:11 AM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Thanks Scott,
> Done, would you mind checking the origin/CURATOR-167 to make sure that I
> haven't done anything wrong! I have done a git pull on a different machine
> and it seems to be ok.
> cheers
>
> On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum <dr...@gmail.com> wrote:
>
> > You just force push your branch.
> >
> > If it's your feature branch, and you know you have it in a good state
> > locally, you can just force push the remote branch into the same state.
> >
> > You'd never want to do that to master, a release branch, or someone
> else's
> > branch.
> > On Aug 24, 2015 11:15 PM, "Cameron McKenzie" <mc...@gmail.com>
> > wrote:
> >
> > > Thanks Mike,
> > > That was a good description. The CURATOR-167 branch is definitely there
> > as
> > > it's been a pull request for the last few months. So, I'll await your
> > > thoughts in the morning. Alternatively, I can just merge master instead
> > of
> > > rebasing it.
> > >
> > > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <ma...@cloudera.com>
> wrote:
> > >
> > > > Yea, that's the big downside with rebasing, is that remotes don't
> > exactly
> > > > keep up with the history. I'm going to try to explain this as best
> as I
> > > > can, but usually I point people towards this excellent "Git for Ages
> 4
> > > and
> > > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he talks
> about
> > > > rebases at the very very end, around the 1:30 mark.
> > > >
> > > > Essentially, your current version of the branch does not have the
> > remote
> > > > version of the as an ancestor. Which is correct, when you did the
> > rebase,
> > > > you wrote a new commit lineage.
> > > >
> > > > I didn't realize that there was already a CURATOR-167 branch pushed
> to
> > > the
> > > > repo when I gave you those steps. I'll have to look at what's going
> on
> > > with
> > > > a fresh set of eyes in the morning.
> > > >
> > > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <
> > > mckenzie.cam@gmail.com>
> > > > wrote:
> > > >
> > > > > I just tried this and obviously I'm doing something wrong.
> > > > >
> > > > > git checkout CURATOR-167
> > > > > git pull
> > > > > git rebase -i origin/master
> > > > >
> > > > > #This gives me a dialog with one commit with pick
> > > > > Save and exit
> > > > > #This gives a merge conflict and leaves me in a detached head state
> > (I
> > > > > presume this is ok).
> > > > > Fix up the merge conflict
> > > > > git rebase --continue
> > > > > #This gives me a dialog to commit the changes
> > > > > Save and exit
> > > > > #Everything seems fine at this point. Builds ok, tests run ok.
> > > > >
> > > > > git push
> > > > >
> > > > > ! [rejected] CURATOR-167 -> CURATOR-167 (non-fast-forward)
> > > > > error: failed to push some refs to '
> > > > > https://git-wip-us.apache.org/repos/asf/curator.git'
> > > > > hint: Updates were rejected because the tip of your current branch
> is
> > > > > behind
> > > > > hint: its remote counterpart. Integrate the remote changes (e.g.
> > > > > hint: 'git pull ...') before pushing again.
> > > > > hint: See the 'Note about fast-forwards' in 'git push --help' for
> > > > details.
> > > > >
> > > > > There have been no changes on the branch since I did the pull
> before
> > > the
> > > > > rebase.
> > > > >
> > > > > Any ideas?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <
> > > > mckenzie.cam@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > Thanks Mike,
> > > > > > Will give it a spin today some time.
> > > > > > cheers
> > > > > >
> > > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <ma...@cloudera.com>
> > > > wrote:
> > > > > >
> > > > > >> if you're going to tray that, here's what you want to do
> (assuming
> > > > > command
> > > > > >> line)
> > > > > >>
> > > > > >> git checkout CURATOR-167 # start with the branch that you are
> > > changing
> > > > > >> git rebase -i master # rebase the current branch on top of the
> > given
> > > > > >> branch
> > > > > >>
> > > > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
> > > > > mckenzie.cam@gmail.com
> > > > > >> >
> > > > > >> wrote:
> > > > > >>
> > > > > >> > Scott,
> > > > > >> > I've been using a similar approach to Jordan given that's what
> > I'm
> > > > > used
> > > > > >> to,
> > > > > >> > but I'm happy to try your approach. I'm going to try and fix
> up
> > > > > >> CURATOR-167
> > > > > >> > as it will no longer cleanly merge (it's been sitting there a
> > > > while).
> > > > > >> So, I
> > > > > >> > should rebase master into the CURATOR-167 branch?
> > > > > >> > cheers
> > > > > >> >
> > > > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <
> > > dragonsinth@apache.org
> > > > >
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > LOL! So sorry to hear that. Yeah, it's definitely possible
> > to
> > > > mess
> > > > > >> > > things up badly. If I'm doing something particularly risky,
> > > I'll
> > > > > just
> > > > > >> > "git
> > > > > >> > > branch original" before I start, so as to leave a branch
> > pointer
> > > > at
> > > > > my
> > > > > >> > > start point as a safe recovery if it goes south. I also use
> > > gitk
> > > > to
> > > > > >> > > visualize sometimes.
> > > > > >> > >
> > > > > >> > > Another major selling point for rebase (-i) is that it's
> > > *really*
> > > > > >> hard to
> > > > > >> > > merge the wrong branch. If the list of commits that comes
> up
> > > > > doesn't
> > > > > >> > look
> > > > > >> > > basically correct, you probably did something wrong-- trying
> > to
> > > > > rebase
> > > > > >> > onto
> > > > > >> > > the wrong branch will give you tons of commits, most of
> which
> > > > aren't
> > > > > >> > yours.
> > > > > >> > >
> > > > > >> > > I think what you've been doing is fine, it's definitely the
> > > right
> > > > > >> > approach
> > > > > >> > > if you're doing a merge strategy! I've just ended up
> > > gravitating
> > > > > to a
> > > > > >> > > rebase strategy over the years for the reasons I've
> mentioned.
> > > > > >> > >
> > > > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> > > > > >> > > jordan@jordanzimmerman.com> wrote:
> > > > > >> > >
> > > > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up several
> > > projects
> > > > > >> with
> > > > > >> > it
> > > > > >> > >> so I can’t even type the letters without breaking into a
> > sweat.
> > > > > "git
> > > > > >> > rebase
> > > > > >> > >> -i” is a lot safer, though. Here’s what I’ve been doing -
> let
> > > me
> > > > > >> know if
> > > > > >> > >> it’s OK. For branches that are off of CURATOR-3.0, I never
> > > merge
> > > > > >> > master. I
> > > > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact,
> > > should
> > > > we
> > > > > >> > have a
> > > > > >> > >> branch naming scheme to enforce this?
> > > > > >> > >>
> > > > > >> > >> -Jordan
> > > > > >> > >>
> > > > > >> > >>
> > > > > >> > >>
> > > > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
> > > > > >> dragonsinth@apache.org)
> > > > > >> > >> wrote:
> > > > > >> > >>
> > > > > >> > >> Correct. When I say "main" branch vs. "feature" branch I
> just
> > > > mean
> > > > > >> the
> > > > > >> > >> stable branch everyone is working against (3.0 or master)
> > vs. a
> > > > > >> feature
> > > > > >> > >> branch where you're actively working.
> > > > > >> > >>
> > > > > >> > >> You'll get to a point in development where you'll think
> "Hey,
> > > > there
> > > > > >> are
> > > > > >> > >> changes on the main branch I'm working against that I
> really
> > > need
> > > > > to
> > > > > >> > pull
> > > > > >> > >> into my feature branch." At that point (particularly if you
> > > have
> > > > an
> > > > > >> svn
> > > > > >> > >> background) you'll be tempted to merge the main branch into
> > > your
> > > > > >> feature
> > > > > >> > >> branch. I would suggest not doing that, as it makes the
> > history
> > > > > very
> > > > > >> > muddy
> > > > > >> > >> to follow. Instead, my workflow is usually more like this:
> > > > > >> > >>
> > > > > >> > >> Suppose I'm working on CURATOR-218. It was originally
> > branched
> > > > off
> > > > > >> 3.0,
> > > > > >> > >> and I want to pull in new changes.
> > > > > >> > >>
> > > > > >> > >> git remote update
> > > > > >> > >> git rebase -i origin/CURATOR-3.0
> > > > > >> > >>
> > > > > >> > >> This pulls up an editor that gives me the list of commits
> to
> > > > > rebase.
> > > > > >> I
> > > > > >> > >> would typically exit out of the editor to at this point to
> > > accept
> > > > > the
> > > > > >> > >> commit list, but if I'm so inclined, I'll do things like
> > > reorder
> > > > > the
> > > > > >> > list,
> > > > > >> > >> or squash commits like like "wip" or "minor reformat" into
> a
> > > more
> > > > > >> > curated
> > > > > >> > >> set of logical commits.
> > > > > >> > >>
> > > > > >> > >> Once you exit the editor, git goes through and applies each
> > > > commit,
> > > > > >> one
> > > > > >> > at
> > > > > >> > >> a time, to the head of the target branch. It's like picking
> > up
> > > > your
> > > > > >> > commit
> > > > > >> > >> chain and dumping it at the end of the target branch, as if
> > all
> > > > > your
> > > > > >> > work
> > > > > >> > >> had been done against what's now the head of that branch.
> > > You'll
> > > > > may
> > > > > >> > have
> > > > > >> > >> to fix conflicts along the way, but usually not much more
> > than
> > > if
> > > > > you
> > > > > >> > did
> > > > > >> > >> it as a merge.
> > > > > >> > >>
> > > > > >> > >> I'd encourage us to try this out a couple times and get a
> > feel
> > > > for
> > > > > >> the
> > > > > >> > >> rebase flow. It's a little more to get your head around at
> > > first,
> > > > > but
> > > > > >> > the
> > > > > >> > >> upside is you end up with really easy to follow commit
> > > histories,
> > > > > >> which
> > > > > >> > >> makes it way easier to untangle problems later if they crop
> > up.
> > > > > >> > >>
> > > > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> > > > > >> > >> jordan@jordanzimmerman.com> wrote:
> > > > > >> > >>
> > > > > >> > >> > Can you explain this in detail? For me, I have some
> > features
> > > > that
> > > > > >> are
> > > > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of
> > master.
> > > > The
> > > > > >> true
> > > > > >> > >> > “master” is Curator 2.x only, right?
> > > > > >> > >> >
> > > > > >> > >> > -Jordan
> > > > > >> > >> >
> > > > > >> > >> >
> > > > > >> > >> >
> > > > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
> > > > > >> dragonsinth@apache.org
> > > > > >> > )
> > > > > >> > >> > wrote:
> > > > > >> > >> >
> > > > > >> > >> > BTW: I noticed a couple of new commits
> > > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> > > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is
> > > > getting
> > > > > >> > merged
> > > > > >> > >> > into feature branches. Almost every project I've been on
> we
> > > > don't
> > > > > >> tend
> > > > > >> > >> to
> > > > > >> > >> > do that as it leads to confusing history (this isn't just
> > > > > >> aesthetic,
> > > > > >> > it
> > > > > >> > >> > can
> > > > > >> > >> > get harder for tooling to figure out what happened). If I
> > > want
> > > > to
> > > > > >> pull
> > > > > >> > >> > changes from the main branch into my feature branch, I
> > would
> > > > > >> typically
> > > > > >> > >> > *rebase* my feature branch against the main branch.
> > > > > >> > >> >
> > > > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
> > > > > >> dragonsinth@apache.org>
> > > > > >> > >> > wrote:
> > > > > >> > >> >
> > > > > >> > >> > > Yeah, 217 & 161 were the first two big things in 3.0.
> > > > > >> > >> > >
> > > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> > > > > >> > >> > > jordan@jordanzimmerman.com> wrote:
> > > > > >> > >> > >
> > > > > >> > >> > >> OK - Also, is CURATOR-161 complete? The issue is still
> > > open
> > > > in
> > > > > >> > Jira.
> > > > > >> > >> > >>
> > > > > >> > >> > >>
> > > > > >> > >> > >>
> > > > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> > > > > >> > >> > >> mckenzie.cam@gmail.com) wrote:
> > > > > >> > >> > >>
> > > > > >> > >> > >> Yes, I merged it in last week some time.
> > > > > >> > >> > >>
> > > > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> > > > > >> > >> > >> jordan@jordanzimmerman.com> wrote:
> > > > > >> > >> > >>
> > > > > >> > >> > >> > Scott, did CURATOR-217 get merged into the new
> > > > CURATOR-3.0?
> > > > > >> > >> > >> >
> > > > > >> > >> > >> > -Jordan
> > > > > >> > >> > >> >
> > > > > >> > >> > >> >
> > > > > >> > >> > >> >
> > > > > >> > >> > >>
> > > > > >> > >> > >
> > > > > >> > >> > >
> > > > > >> > >> >
> > > > > >> > >> >
> > > > > >> > >>
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
Thanks Scott,
Done, would you mind checking the origin/CURATOR-167 to make sure that I
haven't done anything wrong! I have done a git pull on a different machine
and it seems to be ok.
cheers
On Tue, Aug 25, 2015 at 1:49 PM, Scott Blum <dr...@gmail.com> wrote:
> You just force push your branch.
>
> If it's your feature branch, and you know you have it in a good state
> locally, you can just force push the remote branch into the same state.
>
> You'd never want to do that to master, a release branch, or someone else's
> branch.
> On Aug 24, 2015 11:15 PM, "Cameron McKenzie" <mc...@gmail.com>
> wrote:
>
> > Thanks Mike,
> > That was a good description. The CURATOR-167 branch is definitely there
> as
> > it's been a pull request for the last few months. So, I'll await your
> > thoughts in the morning. Alternatively, I can just merge master instead
> of
> > rebasing it.
> >
> > On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <ma...@cloudera.com> wrote:
> >
> > > Yea, that's the big downside with rebasing, is that remotes don't
> exactly
> > > keep up with the history. I'm going to try to explain this as best as I
> > > can, but usually I point people towards this excellent "Git for Ages 4
> > and
> > > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he talks about
> > > rebases at the very very end, around the 1:30 mark.
> > >
> > > Essentially, your current version of the branch does not have the
> remote
> > > version of the as an ancestor. Which is correct, when you did the
> rebase,
> > > you wrote a new commit lineage.
> > >
> > > I didn't realize that there was already a CURATOR-167 branch pushed to
> > the
> > > repo when I gave you those steps. I'll have to look at what's going on
> > with
> > > a fresh set of eyes in the morning.
> > >
> > > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <
> > mckenzie.cam@gmail.com>
> > > wrote:
> > >
> > > > I just tried this and obviously I'm doing something wrong.
> > > >
> > > > git checkout CURATOR-167
> > > > git pull
> > > > git rebase -i origin/master
> > > >
> > > > #This gives me a dialog with one commit with pick
> > > > Save and exit
> > > > #This gives a merge conflict and leaves me in a detached head state
> (I
> > > > presume this is ok).
> > > > Fix up the merge conflict
> > > > git rebase --continue
> > > > #This gives me a dialog to commit the changes
> > > > Save and exit
> > > > #Everything seems fine at this point. Builds ok, tests run ok.
> > > >
> > > > git push
> > > >
> > > > ! [rejected] CURATOR-167 -> CURATOR-167 (non-fast-forward)
> > > > error: failed to push some refs to '
> > > > https://git-wip-us.apache.org/repos/asf/curator.git'
> > > > hint: Updates were rejected because the tip of your current branch is
> > > > behind
> > > > hint: its remote counterpart. Integrate the remote changes (e.g.
> > > > hint: 'git pull ...') before pushing again.
> > > > hint: See the 'Note about fast-forwards' in 'git push --help' for
> > > details.
> > > >
> > > > There have been no changes on the branch since I did the pull before
> > the
> > > > rebase.
> > > >
> > > > Any ideas?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <
> > > mckenzie.cam@gmail.com>
> > > > wrote:
> > > >
> > > > > Thanks Mike,
> > > > > Will give it a spin today some time.
> > > > > cheers
> > > > >
> > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <ma...@cloudera.com>
> > > wrote:
> > > > >
> > > > >> if you're going to tray that, here's what you want to do (assuming
> > > > command
> > > > >> line)
> > > > >>
> > > > >> git checkout CURATOR-167 # start with the branch that you are
> > changing
> > > > >> git rebase -i master # rebase the current branch on top of the
> given
> > > > >> branch
> > > > >>
> > > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
> > > > mckenzie.cam@gmail.com
> > > > >> >
> > > > >> wrote:
> > > > >>
> > > > >> > Scott,
> > > > >> > I've been using a similar approach to Jordan given that's what
> I'm
> > > > used
> > > > >> to,
> > > > >> > but I'm happy to try your approach. I'm going to try and fix up
> > > > >> CURATOR-167
> > > > >> > as it will no longer cleanly merge (it's been sitting there a
> > > while).
> > > > >> So, I
> > > > >> > should rebase master into the CURATOR-167 branch?
> > > > >> > cheers
> > > > >> >
> > > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <
> > dragonsinth@apache.org
> > > >
> > > > >> > wrote:
> > > > >> >
> > > > >> > > LOL! So sorry to hear that. Yeah, it's definitely possible
> to
> > > mess
> > > > >> > > things up badly. If I'm doing something particularly risky,
> > I'll
> > > > just
> > > > >> > "git
> > > > >> > > branch original" before I start, so as to leave a branch
> pointer
> > > at
> > > > my
> > > > >> > > start point as a safe recovery if it goes south. I also use
> > gitk
> > > to
> > > > >> > > visualize sometimes.
> > > > >> > >
> > > > >> > > Another major selling point for rebase (-i) is that it's
> > *really*
> > > > >> hard to
> > > > >> > > merge the wrong branch. If the list of commits that comes up
> > > > doesn't
> > > > >> > look
> > > > >> > > basically correct, you probably did something wrong-- trying
> to
> > > > rebase
> > > > >> > onto
> > > > >> > > the wrong branch will give you tons of commits, most of which
> > > aren't
> > > > >> > yours.
> > > > >> > >
> > > > >> > > I think what you've been doing is fine, it's definitely the
> > right
> > > > >> > approach
> > > > >> > > if you're doing a merge strategy! I've just ended up
> > gravitating
> > > > to a
> > > > >> > > rebase strategy over the years for the reasons I've mentioned.
> > > > >> > >
> > > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> > > > >> > > jordan@jordanzimmerman.com> wrote:
> > > > >> > >
> > > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up several
> > projects
> > > > >> with
> > > > >> > it
> > > > >> > >> so I can’t even type the letters without breaking into a
> sweat.
> > > > "git
> > > > >> > rebase
> > > > >> > >> -i” is a lot safer, though. Here’s what I’ve been doing - let
> > me
> > > > >> know if
> > > > >> > >> it’s OK. For branches that are off of CURATOR-3.0, I never
> > merge
> > > > >> > master. I
> > > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact,
> > should
> > > we
> > > > >> > have a
> > > > >> > >> branch naming scheme to enforce this?
> > > > >> > >>
> > > > >> > >> -Jordan
> > > > >> > >>
> > > > >> > >>
> > > > >> > >>
> > > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
> > > > >> dragonsinth@apache.org)
> > > > >> > >> wrote:
> > > > >> > >>
> > > > >> > >> Correct. When I say "main" branch vs. "feature" branch I just
> > > mean
> > > > >> the
> > > > >> > >> stable branch everyone is working against (3.0 or master)
> vs. a
> > > > >> feature
> > > > >> > >> branch where you're actively working.
> > > > >> > >>
> > > > >> > >> You'll get to a point in development where you'll think "Hey,
> > > there
> > > > >> are
> > > > >> > >> changes on the main branch I'm working against that I really
> > need
> > > > to
> > > > >> > pull
> > > > >> > >> into my feature branch." At that point (particularly if you
> > have
> > > an
> > > > >> svn
> > > > >> > >> background) you'll be tempted to merge the main branch into
> > your
> > > > >> feature
> > > > >> > >> branch. I would suggest not doing that, as it makes the
> history
> > > > very
> > > > >> > muddy
> > > > >> > >> to follow. Instead, my workflow is usually more like this:
> > > > >> > >>
> > > > >> > >> Suppose I'm working on CURATOR-218. It was originally
> branched
> > > off
> > > > >> 3.0,
> > > > >> > >> and I want to pull in new changes.
> > > > >> > >>
> > > > >> > >> git remote update
> > > > >> > >> git rebase -i origin/CURATOR-3.0
> > > > >> > >>
> > > > >> > >> This pulls up an editor that gives me the list of commits to
> > > > rebase.
> > > > >> I
> > > > >> > >> would typically exit out of the editor to at this point to
> > accept
> > > > the
> > > > >> > >> commit list, but if I'm so inclined, I'll do things like
> > reorder
> > > > the
> > > > >> > list,
> > > > >> > >> or squash commits like like "wip" or "minor reformat" into a
> > more
> > > > >> > curated
> > > > >> > >> set of logical commits.
> > > > >> > >>
> > > > >> > >> Once you exit the editor, git goes through and applies each
> > > commit,
> > > > >> one
> > > > >> > at
> > > > >> > >> a time, to the head of the target branch. It's like picking
> up
> > > your
> > > > >> > commit
> > > > >> > >> chain and dumping it at the end of the target branch, as if
> all
> > > > your
> > > > >> > work
> > > > >> > >> had been done against what's now the head of that branch.
> > You'll
> > > > may
> > > > >> > have
> > > > >> > >> to fix conflicts along the way, but usually not much more
> than
> > if
> > > > you
> > > > >> > did
> > > > >> > >> it as a merge.
> > > > >> > >>
> > > > >> > >> I'd encourage us to try this out a couple times and get a
> feel
> > > for
> > > > >> the
> > > > >> > >> rebase flow. It's a little more to get your head around at
> > first,
> > > > but
> > > > >> > the
> > > > >> > >> upside is you end up with really easy to follow commit
> > histories,
> > > > >> which
> > > > >> > >> makes it way easier to untangle problems later if they crop
> up.
> > > > >> > >>
> > > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> > > > >> > >> jordan@jordanzimmerman.com> wrote:
> > > > >> > >>
> > > > >> > >> > Can you explain this in detail? For me, I have some
> features
> > > that
> > > > >> are
> > > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of
> master.
> > > The
> > > > >> true
> > > > >> > >> > “master” is Curator 2.x only, right?
> > > > >> > >> >
> > > > >> > >> > -Jordan
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
> > > > >> dragonsinth@apache.org
> > > > >> > )
> > > > >> > >> > wrote:
> > > > >> > >> >
> > > > >> > >> > BTW: I noticed a couple of new commits
> > > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> > > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is
> > > getting
> > > > >> > merged
> > > > >> > >> > into feature branches. Almost every project I've been on we
> > > don't
> > > > >> tend
> > > > >> > >> to
> > > > >> > >> > do that as it leads to confusing history (this isn't just
> > > > >> aesthetic,
> > > > >> > it
> > > > >> > >> > can
> > > > >> > >> > get harder for tooling to figure out what happened). If I
> > want
> > > to
> > > > >> pull
> > > > >> > >> > changes from the main branch into my feature branch, I
> would
> > > > >> typically
> > > > >> > >> > *rebase* my feature branch against the main branch.
> > > > >> > >> >
> > > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
> > > > >> dragonsinth@apache.org>
> > > > >> > >> > wrote:
> > > > >> > >> >
> > > > >> > >> > > Yeah, 217 & 161 were the first two big things in 3.0.
> > > > >> > >> > >
> > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> > > > >> > >> > > jordan@jordanzimmerman.com> wrote:
> > > > >> > >> > >
> > > > >> > >> > >> OK - Also, is CURATOR-161 complete? The issue is still
> > open
> > > in
> > > > >> > Jira.
> > > > >> > >> > >>
> > > > >> > >> > >>
> > > > >> > >> > >>
> > > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> > > > >> > >> > >> mckenzie.cam@gmail.com) wrote:
> > > > >> > >> > >>
> > > > >> > >> > >> Yes, I merged it in last week some time.
> > > > >> > >> > >>
> > > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> > > > >> > >> > >> jordan@jordanzimmerman.com> wrote:
> > > > >> > >> > >>
> > > > >> > >> > >> > Scott, did CURATOR-217 get merged into the new
> > > CURATOR-3.0?
> > > > >> > >> > >> >
> > > > >> > >> > >> > -Jordan
> > > > >> > >> > >> >
> > > > >> > >> > >> >
> > > > >> > >> > >> >
> > > > >> > >> > >>
> > > > >> > >> > >
> > > > >> > >> > >
> > > > >> > >> >
> > > > >> > >> >
> > > > >> > >>
> > > > >> > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > > >
> > > > >
> > > >
> > >
> >
>
Re: CURATOR-217?
Posted by Scott Blum <dr...@gmail.com>.
You just force push your branch.
If it's your feature branch, and you know you have it in a good state
locally, you can just force push the remote branch into the same state.
You'd never want to do that to master, a release branch, or someone else's
branch.
On Aug 24, 2015 11:15 PM, "Cameron McKenzie" <mc...@gmail.com> wrote:
> Thanks Mike,
> That was a good description. The CURATOR-167 branch is definitely there as
> it's been a pull request for the last few months. So, I'll await your
> thoughts in the morning. Alternatively, I can just merge master instead of
> rebasing it.
>
> On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <ma...@cloudera.com> wrote:
>
> > Yea, that's the big downside with rebasing, is that remotes don't exactly
> > keep up with the history. I'm going to try to explain this as best as I
> > can, but usually I point people towards this excellent "Git for Ages 4
> and
> > Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he talks about
> > rebases at the very very end, around the 1:30 mark.
> >
> > Essentially, your current version of the branch does not have the remote
> > version of the as an ancestor. Which is correct, when you did the rebase,
> > you wrote a new commit lineage.
> >
> > I didn't realize that there was already a CURATOR-167 branch pushed to
> the
> > repo when I gave you those steps. I'll have to look at what's going on
> with
> > a fresh set of eyes in the morning.
> >
> > On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <
> mckenzie.cam@gmail.com>
> > wrote:
> >
> > > I just tried this and obviously I'm doing something wrong.
> > >
> > > git checkout CURATOR-167
> > > git pull
> > > git rebase -i origin/master
> > >
> > > #This gives me a dialog with one commit with pick
> > > Save and exit
> > > #This gives a merge conflict and leaves me in a detached head state (I
> > > presume this is ok).
> > > Fix up the merge conflict
> > > git rebase --continue
> > > #This gives me a dialog to commit the changes
> > > Save and exit
> > > #Everything seems fine at this point. Builds ok, tests run ok.
> > >
> > > git push
> > >
> > > ! [rejected] CURATOR-167 -> CURATOR-167 (non-fast-forward)
> > > error: failed to push some refs to '
> > > https://git-wip-us.apache.org/repos/asf/curator.git'
> > > hint: Updates were rejected because the tip of your current branch is
> > > behind
> > > hint: its remote counterpart. Integrate the remote changes (e.g.
> > > hint: 'git pull ...') before pushing again.
> > > hint: See the 'Note about fast-forwards' in 'git push --help' for
> > details.
> > >
> > > There have been no changes on the branch since I did the pull before
> the
> > > rebase.
> > >
> > > Any ideas?
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <
> > mckenzie.cam@gmail.com>
> > > wrote:
> > >
> > > > Thanks Mike,
> > > > Will give it a spin today some time.
> > > > cheers
> > > >
> > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <ma...@cloudera.com>
> > wrote:
> > > >
> > > >> if you're going to tray that, here's what you want to do (assuming
> > > command
> > > >> line)
> > > >>
> > > >> git checkout CURATOR-167 # start with the branch that you are
> changing
> > > >> git rebase -i master # rebase the current branch on top of the given
> > > >> branch
> > > >>
> > > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
> > > mckenzie.cam@gmail.com
> > > >> >
> > > >> wrote:
> > > >>
> > > >> > Scott,
> > > >> > I've been using a similar approach to Jordan given that's what I'm
> > > used
> > > >> to,
> > > >> > but I'm happy to try your approach. I'm going to try and fix up
> > > >> CURATOR-167
> > > >> > as it will no longer cleanly merge (it's been sitting there a
> > while).
> > > >> So, I
> > > >> > should rebase master into the CURATOR-167 branch?
> > > >> > cheers
> > > >> >
> > > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <
> dragonsinth@apache.org
> > >
> > > >> > wrote:
> > > >> >
> > > >> > > LOL! So sorry to hear that. Yeah, it's definitely possible to
> > mess
> > > >> > > things up badly. If I'm doing something particularly risky,
> I'll
> > > just
> > > >> > "git
> > > >> > > branch original" before I start, so as to leave a branch pointer
> > at
> > > my
> > > >> > > start point as a safe recovery if it goes south. I also use
> gitk
> > to
> > > >> > > visualize sometimes.
> > > >> > >
> > > >> > > Another major selling point for rebase (-i) is that it's
> *really*
> > > >> hard to
> > > >> > > merge the wrong branch. If the list of commits that comes up
> > > doesn't
> > > >> > look
> > > >> > > basically correct, you probably did something wrong-- trying to
> > > rebase
> > > >> > onto
> > > >> > > the wrong branch will give you tons of commits, most of which
> > aren't
> > > >> > yours.
> > > >> > >
> > > >> > > I think what you've been doing is fine, it's definitely the
> right
> > > >> > approach
> > > >> > > if you're doing a merge strategy! I've just ended up
> gravitating
> > > to a
> > > >> > > rebase strategy over the years for the reasons I've mentioned.
> > > >> > >
> > > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> > > >> > > jordan@jordanzimmerman.com> wrote:
> > > >> > >
> > > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up several
> projects
> > > >> with
> > > >> > it
> > > >> > >> so I can’t even type the letters without breaking into a sweat.
> > > "git
> > > >> > rebase
> > > >> > >> -i” is a lot safer, though. Here’s what I’ve been doing - let
> me
> > > >> know if
> > > >> > >> it’s OK. For branches that are off of CURATOR-3.0, I never
> merge
> > > >> > master. I
> > > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact,
> should
> > we
> > > >> > have a
> > > >> > >> branch naming scheme to enforce this?
> > > >> > >>
> > > >> > >> -Jordan
> > > >> > >>
> > > >> > >>
> > > >> > >>
> > > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
> > > >> dragonsinth@apache.org)
> > > >> > >> wrote:
> > > >> > >>
> > > >> > >> Correct. When I say "main" branch vs. "feature" branch I just
> > mean
> > > >> the
> > > >> > >> stable branch everyone is working against (3.0 or master) vs. a
> > > >> feature
> > > >> > >> branch where you're actively working.
> > > >> > >>
> > > >> > >> You'll get to a point in development where you'll think "Hey,
> > there
> > > >> are
> > > >> > >> changes on the main branch I'm working against that I really
> need
> > > to
> > > >> > pull
> > > >> > >> into my feature branch." At that point (particularly if you
> have
> > an
> > > >> svn
> > > >> > >> background) you'll be tempted to merge the main branch into
> your
> > > >> feature
> > > >> > >> branch. I would suggest not doing that, as it makes the history
> > > very
> > > >> > muddy
> > > >> > >> to follow. Instead, my workflow is usually more like this:
> > > >> > >>
> > > >> > >> Suppose I'm working on CURATOR-218. It was originally branched
> > off
> > > >> 3.0,
> > > >> > >> and I want to pull in new changes.
> > > >> > >>
> > > >> > >> git remote update
> > > >> > >> git rebase -i origin/CURATOR-3.0
> > > >> > >>
> > > >> > >> This pulls up an editor that gives me the list of commits to
> > > rebase.
> > > >> I
> > > >> > >> would typically exit out of the editor to at this point to
> accept
> > > the
> > > >> > >> commit list, but if I'm so inclined, I'll do things like
> reorder
> > > the
> > > >> > list,
> > > >> > >> or squash commits like like "wip" or "minor reformat" into a
> more
> > > >> > curated
> > > >> > >> set of logical commits.
> > > >> > >>
> > > >> > >> Once you exit the editor, git goes through and applies each
> > commit,
> > > >> one
> > > >> > at
> > > >> > >> a time, to the head of the target branch. It's like picking up
> > your
> > > >> > commit
> > > >> > >> chain and dumping it at the end of the target branch, as if all
> > > your
> > > >> > work
> > > >> > >> had been done against what's now the head of that branch.
> You'll
> > > may
> > > >> > have
> > > >> > >> to fix conflicts along the way, but usually not much more than
> if
> > > you
> > > >> > did
> > > >> > >> it as a merge.
> > > >> > >>
> > > >> > >> I'd encourage us to try this out a couple times and get a feel
> > for
> > > >> the
> > > >> > >> rebase flow. It's a little more to get your head around at
> first,
> > > but
> > > >> > the
> > > >> > >> upside is you end up with really easy to follow commit
> histories,
> > > >> which
> > > >> > >> makes it way easier to untangle problems later if they crop up.
> > > >> > >>
> > > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> > > >> > >> jordan@jordanzimmerman.com> wrote:
> > > >> > >>
> > > >> > >> > Can you explain this in detail? For me, I have some features
> > that
> > > >> are
> > > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master.
> > The
> > > >> true
> > > >> > >> > “master” is Curator 2.x only, right?
> > > >> > >> >
> > > >> > >> > -Jordan
> > > >> > >> >
> > > >> > >> >
> > > >> > >> >
> > > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
> > > >> dragonsinth@apache.org
> > > >> > )
> > > >> > >> > wrote:
> > > >> > >> >
> > > >> > >> > BTW: I noticed a couple of new commits
> > > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> > > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is
> > getting
> > > >> > merged
> > > >> > >> > into feature branches. Almost every project I've been on we
> > don't
> > > >> tend
> > > >> > >> to
> > > >> > >> > do that as it leads to confusing history (this isn't just
> > > >> aesthetic,
> > > >> > it
> > > >> > >> > can
> > > >> > >> > get harder for tooling to figure out what happened). If I
> want
> > to
> > > >> pull
> > > >> > >> > changes from the main branch into my feature branch, I would
> > > >> typically
> > > >> > >> > *rebase* my feature branch against the main branch.
> > > >> > >> >
> > > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
> > > >> dragonsinth@apache.org>
> > > >> > >> > wrote:
> > > >> > >> >
> > > >> > >> > > Yeah, 217 & 161 were the first two big things in 3.0.
> > > >> > >> > >
> > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> > > >> > >> > > jordan@jordanzimmerman.com> wrote:
> > > >> > >> > >
> > > >> > >> > >> OK - Also, is CURATOR-161 complete? The issue is still
> open
> > in
> > > >> > Jira.
> > > >> > >> > >>
> > > >> > >> > >>
> > > >> > >> > >>
> > > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> > > >> > >> > >> mckenzie.cam@gmail.com) wrote:
> > > >> > >> > >>
> > > >> > >> > >> Yes, I merged it in last week some time.
> > > >> > >> > >>
> > > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> > > >> > >> > >> jordan@jordanzimmerman.com> wrote:
> > > >> > >> > >>
> > > >> > >> > >> > Scott, did CURATOR-217 get merged into the new
> > CURATOR-3.0?
> > > >> > >> > >> >
> > > >> > >> > >> > -Jordan
> > > >> > >> > >> >
> > > >> > >> > >> >
> > > >> > >> > >> >
> > > >> > >> > >>
> > > >> > >> > >
> > > >> > >> > >
> > > >> > >> >
> > > >> > >> >
> > > >> > >>
> > > >> > >
> > > >> > >
> > > >> >
> > > >>
> > > >
> > > >
> > >
> >
>
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
Thanks Mike,
That was a good description. The CURATOR-167 branch is definitely there as
it's been a pull request for the last few months. So, I'll await your
thoughts in the morning. Alternatively, I can just merge master instead of
rebasing it.
On Tue, Aug 25, 2015 at 1:00 PM, Mike Drob <ma...@cloudera.com> wrote:
> Yea, that's the big downside with rebasing, is that remotes don't exactly
> keep up with the history. I'm going to try to explain this as best as I
> can, but usually I point people towards this excellent "Git for Ages 4 and
> Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he talks about
> rebases at the very very end, around the 1:30 mark.
>
> Essentially, your current version of the branch does not have the remote
> version of the as an ancestor. Which is correct, when you did the rebase,
> you wrote a new commit lineage.
>
> I didn't realize that there was already a CURATOR-167 branch pushed to the
> repo when I gave you those steps. I'll have to look at what's going on with
> a fresh set of eyes in the morning.
>
> On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
> > I just tried this and obviously I'm doing something wrong.
> >
> > git checkout CURATOR-167
> > git pull
> > git rebase -i origin/master
> >
> > #This gives me a dialog with one commit with pick
> > Save and exit
> > #This gives a merge conflict and leaves me in a detached head state (I
> > presume this is ok).
> > Fix up the merge conflict
> > git rebase --continue
> > #This gives me a dialog to commit the changes
> > Save and exit
> > #Everything seems fine at this point. Builds ok, tests run ok.
> >
> > git push
> >
> > ! [rejected] CURATOR-167 -> CURATOR-167 (non-fast-forward)
> > error: failed to push some refs to '
> > https://git-wip-us.apache.org/repos/asf/curator.git'
> > hint: Updates were rejected because the tip of your current branch is
> > behind
> > hint: its remote counterpart. Integrate the remote changes (e.g.
> > hint: 'git pull ...') before pushing again.
> > hint: See the 'Note about fast-forwards' in 'git push --help' for
> details.
> >
> > There have been no changes on the branch since I did the pull before the
> > rebase.
> >
> > Any ideas?
> >
> >
> >
> >
> >
> >
> > On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <
> mckenzie.cam@gmail.com>
> > wrote:
> >
> > > Thanks Mike,
> > > Will give it a spin today some time.
> > > cheers
> > >
> > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <ma...@cloudera.com>
> wrote:
> > >
> > >> if you're going to tray that, here's what you want to do (assuming
> > command
> > >> line)
> > >>
> > >> git checkout CURATOR-167 # start with the branch that you are changing
> > >> git rebase -i master # rebase the current branch on top of the given
> > >> branch
> > >>
> > >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
> > mckenzie.cam@gmail.com
> > >> >
> > >> wrote:
> > >>
> > >> > Scott,
> > >> > I've been using a similar approach to Jordan given that's what I'm
> > used
> > >> to,
> > >> > but I'm happy to try your approach. I'm going to try and fix up
> > >> CURATOR-167
> > >> > as it will no longer cleanly merge (it's been sitting there a
> while).
> > >> So, I
> > >> > should rebase master into the CURATOR-167 branch?
> > >> > cheers
> > >> >
> > >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <dragonsinth@apache.org
> >
> > >> > wrote:
> > >> >
> > >> > > LOL! So sorry to hear that. Yeah, it's definitely possible to
> mess
> > >> > > things up badly. If I'm doing something particularly risky, I'll
> > just
> > >> > "git
> > >> > > branch original" before I start, so as to leave a branch pointer
> at
> > my
> > >> > > start point as a safe recovery if it goes south. I also use gitk
> to
> > >> > > visualize sometimes.
> > >> > >
> > >> > > Another major selling point for rebase (-i) is that it's *really*
> > >> hard to
> > >> > > merge the wrong branch. If the list of commits that comes up
> > doesn't
> > >> > look
> > >> > > basically correct, you probably did something wrong-- trying to
> > rebase
> > >> > onto
> > >> > > the wrong branch will give you tons of commits, most of which
> aren't
> > >> > yours.
> > >> > >
> > >> > > I think what you've been doing is fine, it's definitely the right
> > >> > approach
> > >> > > if you're doing a merge strategy! I've just ended up gravitating
> > to a
> > >> > > rebase strategy over the years for the reasons I've mentioned.
> > >> > >
> > >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> > >> > > jordan@jordanzimmerman.com> wrote:
> > >> > >
> > >> > >> I’ll admit that rebase terrifies me. I’ve f’d up several projects
> > >> with
> > >> > it
> > >> > >> so I can’t even type the letters without breaking into a sweat.
> > "git
> > >> > rebase
> > >> > >> -i” is a lot safer, though. Here’s what I’ve been doing - let me
> > >> know if
> > >> > >> it’s OK. For branches that are off of CURATOR-3.0, I never merge
> > >> > master. I
> > >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact, should
> we
> > >> > have a
> > >> > >> branch naming scheme to enforce this?
> > >> > >>
> > >> > >> -Jordan
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
> > >> dragonsinth@apache.org)
> > >> > >> wrote:
> > >> > >>
> > >> > >> Correct. When I say "main" branch vs. "feature" branch I just
> mean
> > >> the
> > >> > >> stable branch everyone is working against (3.0 or master) vs. a
> > >> feature
> > >> > >> branch where you're actively working.
> > >> > >>
> > >> > >> You'll get to a point in development where you'll think "Hey,
> there
> > >> are
> > >> > >> changes on the main branch I'm working against that I really need
> > to
> > >> > pull
> > >> > >> into my feature branch." At that point (particularly if you have
> an
> > >> svn
> > >> > >> background) you'll be tempted to merge the main branch into your
> > >> feature
> > >> > >> branch. I would suggest not doing that, as it makes the history
> > very
> > >> > muddy
> > >> > >> to follow. Instead, my workflow is usually more like this:
> > >> > >>
> > >> > >> Suppose I'm working on CURATOR-218. It was originally branched
> off
> > >> 3.0,
> > >> > >> and I want to pull in new changes.
> > >> > >>
> > >> > >> git remote update
> > >> > >> git rebase -i origin/CURATOR-3.0
> > >> > >>
> > >> > >> This pulls up an editor that gives me the list of commits to
> > rebase.
> > >> I
> > >> > >> would typically exit out of the editor to at this point to accept
> > the
> > >> > >> commit list, but if I'm so inclined, I'll do things like reorder
> > the
> > >> > list,
> > >> > >> or squash commits like like "wip" or "minor reformat" into a more
> > >> > curated
> > >> > >> set of logical commits.
> > >> > >>
> > >> > >> Once you exit the editor, git goes through and applies each
> commit,
> > >> one
> > >> > at
> > >> > >> a time, to the head of the target branch. It's like picking up
> your
> > >> > commit
> > >> > >> chain and dumping it at the end of the target branch, as if all
> > your
> > >> > work
> > >> > >> had been done against what's now the head of that branch. You'll
> > may
> > >> > have
> > >> > >> to fix conflicts along the way, but usually not much more than if
> > you
> > >> > did
> > >> > >> it as a merge.
> > >> > >>
> > >> > >> I'd encourage us to try this out a couple times and get a feel
> for
> > >> the
> > >> > >> rebase flow. It's a little more to get your head around at first,
> > but
> > >> > the
> > >> > >> upside is you end up with really easy to follow commit histories,
> > >> which
> > >> > >> makes it way easier to untangle problems later if they crop up.
> > >> > >>
> > >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> > >> > >> jordan@jordanzimmerman.com> wrote:
> > >> > >>
> > >> > >> > Can you explain this in detail? For me, I have some features
> that
> > >> are
> > >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master.
> The
> > >> true
> > >> > >> > “master” is Curator 2.x only, right?
> > >> > >> >
> > >> > >> > -Jordan
> > >> > >> >
> > >> > >> >
> > >> > >> >
> > >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
> > >> dragonsinth@apache.org
> > >> > )
> > >> > >> > wrote:
> > >> > >> >
> > >> > >> > BTW: I noticed a couple of new commits
> > >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> > >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is
> getting
> > >> > merged
> > >> > >> > into feature branches. Almost every project I've been on we
> don't
> > >> tend
> > >> > >> to
> > >> > >> > do that as it leads to confusing history (this isn't just
> > >> aesthetic,
> > >> > it
> > >> > >> > can
> > >> > >> > get harder for tooling to figure out what happened). If I want
> to
> > >> pull
> > >> > >> > changes from the main branch into my feature branch, I would
> > >> typically
> > >> > >> > *rebase* my feature branch against the main branch.
> > >> > >> >
> > >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
> > >> dragonsinth@apache.org>
> > >> > >> > wrote:
> > >> > >> >
> > >> > >> > > Yeah, 217 & 161 were the first two big things in 3.0.
> > >> > >> > >
> > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> > >> > >> > > jordan@jordanzimmerman.com> wrote:
> > >> > >> > >
> > >> > >> > >> OK - Also, is CURATOR-161 complete? The issue is still open
> in
> > >> > Jira.
> > >> > >> > >>
> > >> > >> > >>
> > >> > >> > >>
> > >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> > >> > >> > >> mckenzie.cam@gmail.com) wrote:
> > >> > >> > >>
> > >> > >> > >> Yes, I merged it in last week some time.
> > >> > >> > >>
> > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> > >> > >> > >> jordan@jordanzimmerman.com> wrote:
> > >> > >> > >>
> > >> > >> > >> > Scott, did CURATOR-217 get merged into the new
> CURATOR-3.0?
> > >> > >> > >> >
> > >> > >> > >> > -Jordan
> > >> > >> > >> >
> > >> > >> > >> >
> > >> > >> > >> >
> > >> > >> > >>
> > >> > >> > >
> > >> > >> > >
> > >> > >> >
> > >> > >> >
> > >> > >>
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>
Re: CURATOR-217?
Posted by Mike Drob <ma...@cloudera.com>.
Yea, that's the big downside with rebasing, is that remotes don't exactly
keep up with the history. I'm going to try to explain this as best as I
can, but usually I point people towards this excellent "Git for Ages 4 and
Up" video https://www.youtube.com/watch?v=1ffBJ4sVUb4 - he talks about
rebases at the very very end, around the 1:30 mark.
Essentially, your current version of the branch does not have the remote
version of the as an ancestor. Which is correct, when you did the rebase,
you wrote a new commit lineage.
I didn't realize that there was already a CURATOR-167 branch pushed to the
repo when I gave you those steps. I'll have to look at what's going on with
a fresh set of eyes in the morning.
On Mon, Aug 24, 2015 at 8:37 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> I just tried this and obviously I'm doing something wrong.
>
> git checkout CURATOR-167
> git pull
> git rebase -i origin/master
>
> #This gives me a dialog with one commit with pick
> Save and exit
> #This gives a merge conflict and leaves me in a detached head state (I
> presume this is ok).
> Fix up the merge conflict
> git rebase --continue
> #This gives me a dialog to commit the changes
> Save and exit
> #Everything seems fine at this point. Builds ok, tests run ok.
>
> git push
>
> ! [rejected] CURATOR-167 -> CURATOR-167 (non-fast-forward)
> error: failed to push some refs to '
> https://git-wip-us.apache.org/repos/asf/curator.git'
> hint: Updates were rejected because the tip of your current branch is
> behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
> There have been no changes on the branch since I did the pull before the
> rebase.
>
> Any ideas?
>
>
>
>
>
>
> On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
> > Thanks Mike,
> > Will give it a spin today some time.
> > cheers
> >
> > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <ma...@cloudera.com> wrote:
> >
> >> if you're going to tray that, here's what you want to do (assuming
> command
> >> line)
> >>
> >> git checkout CURATOR-167 # start with the branch that you are changing
> >> git rebase -i master # rebase the current branch on top of the given
> >> branch
> >>
> >> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <
> mckenzie.cam@gmail.com
> >> >
> >> wrote:
> >>
> >> > Scott,
> >> > I've been using a similar approach to Jordan given that's what I'm
> used
> >> to,
> >> > but I'm happy to try your approach. I'm going to try and fix up
> >> CURATOR-167
> >> > as it will no longer cleanly merge (it's been sitting there a while).
> >> So, I
> >> > should rebase master into the CURATOR-167 branch?
> >> > cheers
> >> >
> >> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <dr...@apache.org>
> >> > wrote:
> >> >
> >> > > LOL! So sorry to hear that. Yeah, it's definitely possible to mess
> >> > > things up badly. If I'm doing something particularly risky, I'll
> just
> >> > "git
> >> > > branch original" before I start, so as to leave a branch pointer at
> my
> >> > > start point as a safe recovery if it goes south. I also use gitk to
> >> > > visualize sometimes.
> >> > >
> >> > > Another major selling point for rebase (-i) is that it's *really*
> >> hard to
> >> > > merge the wrong branch. If the list of commits that comes up
> doesn't
> >> > look
> >> > > basically correct, you probably did something wrong-- trying to
> rebase
> >> > onto
> >> > > the wrong branch will give you tons of commits, most of which aren't
> >> > yours.
> >> > >
> >> > > I think what you've been doing is fine, it's definitely the right
> >> > approach
> >> > > if you're doing a merge strategy! I've just ended up gravitating
> to a
> >> > > rebase strategy over the years for the reasons I've mentioned.
> >> > >
> >> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> >> > > jordan@jordanzimmerman.com> wrote:
> >> > >
> >> > >> I’ll admit that rebase terrifies me. I’ve f’d up several projects
> >> with
> >> > it
> >> > >> so I can’t even type the letters without breaking into a sweat.
> "git
> >> > rebase
> >> > >> -i” is a lot safer, though. Here’s what I’ve been doing - let me
> >> know if
> >> > >> it’s OK. For branches that are off of CURATOR-3.0, I never merge
> >> > master. I
> >> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact, should we
> >> > have a
> >> > >> branch naming scheme to enforce this?
> >> > >>
> >> > >> -Jordan
> >> > >>
> >> > >>
> >> > >>
> >> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
> >> dragonsinth@apache.org)
> >> > >> wrote:
> >> > >>
> >> > >> Correct. When I say "main" branch vs. "feature" branch I just mean
> >> the
> >> > >> stable branch everyone is working against (3.0 or master) vs. a
> >> feature
> >> > >> branch where you're actively working.
> >> > >>
> >> > >> You'll get to a point in development where you'll think "Hey, there
> >> are
> >> > >> changes on the main branch I'm working against that I really need
> to
> >> > pull
> >> > >> into my feature branch." At that point (particularly if you have an
> >> svn
> >> > >> background) you'll be tempted to merge the main branch into your
> >> feature
> >> > >> branch. I would suggest not doing that, as it makes the history
> very
> >> > muddy
> >> > >> to follow. Instead, my workflow is usually more like this:
> >> > >>
> >> > >> Suppose I'm working on CURATOR-218. It was originally branched off
> >> 3.0,
> >> > >> and I want to pull in new changes.
> >> > >>
> >> > >> git remote update
> >> > >> git rebase -i origin/CURATOR-3.0
> >> > >>
> >> > >> This pulls up an editor that gives me the list of commits to
> rebase.
> >> I
> >> > >> would typically exit out of the editor to at this point to accept
> the
> >> > >> commit list, but if I'm so inclined, I'll do things like reorder
> the
> >> > list,
> >> > >> or squash commits like like "wip" or "minor reformat" into a more
> >> > curated
> >> > >> set of logical commits.
> >> > >>
> >> > >> Once you exit the editor, git goes through and applies each commit,
> >> one
> >> > at
> >> > >> a time, to the head of the target branch. It's like picking up your
> >> > commit
> >> > >> chain and dumping it at the end of the target branch, as if all
> your
> >> > work
> >> > >> had been done against what's now the head of that branch. You'll
> may
> >> > have
> >> > >> to fix conflicts along the way, but usually not much more than if
> you
> >> > did
> >> > >> it as a merge.
> >> > >>
> >> > >> I'd encourage us to try this out a couple times and get a feel for
> >> the
> >> > >> rebase flow. It's a little more to get your head around at first,
> but
> >> > the
> >> > >> upside is you end up with really easy to follow commit histories,
> >> which
> >> > >> makes it way easier to untangle problems later if they crop up.
> >> > >>
> >> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> >> > >> jordan@jordanzimmerman.com> wrote:
> >> > >>
> >> > >> > Can you explain this in detail? For me, I have some features that
> >> are
> >> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master. The
> >> true
> >> > >> > “master” is Curator 2.x only, right?
> >> > >> >
> >> > >> > -Jordan
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
> >> dragonsinth@apache.org
> >> > )
> >> > >> > wrote:
> >> > >> >
> >> > >> > BTW: I noticed a couple of new commits
> >> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> >> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting
> >> > merged
> >> > >> > into feature branches. Almost every project I've been on we don't
> >> tend
> >> > >> to
> >> > >> > do that as it leads to confusing history (this isn't just
> >> aesthetic,
> >> > it
> >> > >> > can
> >> > >> > get harder for tooling to figure out what happened). If I want to
> >> pull
> >> > >> > changes from the main branch into my feature branch, I would
> >> typically
> >> > >> > *rebase* my feature branch against the main branch.
> >> > >> >
> >> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
> >> dragonsinth@apache.org>
> >> > >> > wrote:
> >> > >> >
> >> > >> > > Yeah, 217 & 161 were the first two big things in 3.0.
> >> > >> > >
> >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> >> > >> > > jordan@jordanzimmerman.com> wrote:
> >> > >> > >
> >> > >> > >> OK - Also, is CURATOR-161 complete? The issue is still open in
> >> > Jira.
> >> > >> > >>
> >> > >> > >>
> >> > >> > >>
> >> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> >> > >> > >> mckenzie.cam@gmail.com) wrote:
> >> > >> > >>
> >> > >> > >> Yes, I merged it in last week some time.
> >> > >> > >>
> >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> >> > >> > >> jordan@jordanzimmerman.com> wrote:
> >> > >> > >>
> >> > >> > >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
> >> > >> > >> >
> >> > >> > >> > -Jordan
> >> > >> > >> >
> >> > >> > >> >
> >> > >> > >> >
> >> > >> > >>
> >> > >> > >
> >> > >> > >
> >> > >> >
> >> > >> >
> >> > >>
> >> > >
> >> > >
> >> >
> >>
> >
> >
>
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
I just tried this and obviously I'm doing something wrong.
git checkout CURATOR-167
git pull
git rebase -i origin/master
#This gives me a dialog with one commit with pick
Save and exit
#This gives a merge conflict and leaves me in a detached head state (I
presume this is ok).
Fix up the merge conflict
git rebase --continue
#This gives me a dialog to commit the changes
Save and exit
#Everything seems fine at this point. Builds ok, tests run ok.
git push
! [rejected] CURATOR-167 -> CURATOR-167 (non-fast-forward)
error: failed to push some refs to '
https://git-wip-us.apache.org/repos/asf/curator.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
There have been no changes on the branch since I did the pull before the
rebase.
Any ideas?
On Tue, Aug 25, 2015 at 8:48 AM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Thanks Mike,
> Will give it a spin today some time.
> cheers
>
> On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <ma...@cloudera.com> wrote:
>
>> if you're going to tray that, here's what you want to do (assuming command
>> line)
>>
>> git checkout CURATOR-167 # start with the branch that you are changing
>> git rebase -i master # rebase the current branch on top of the given
>> branch
>>
>> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <mckenzie.cam@gmail.com
>> >
>> wrote:
>>
>> > Scott,
>> > I've been using a similar approach to Jordan given that's what I'm used
>> to,
>> > but I'm happy to try your approach. I'm going to try and fix up
>> CURATOR-167
>> > as it will no longer cleanly merge (it's been sitting there a while).
>> So, I
>> > should rebase master into the CURATOR-167 branch?
>> > cheers
>> >
>> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <dr...@apache.org>
>> > wrote:
>> >
>> > > LOL! So sorry to hear that. Yeah, it's definitely possible to mess
>> > > things up badly. If I'm doing something particularly risky, I'll just
>> > "git
>> > > branch original" before I start, so as to leave a branch pointer at my
>> > > start point as a safe recovery if it goes south. I also use gitk to
>> > > visualize sometimes.
>> > >
>> > > Another major selling point for rebase (-i) is that it's *really*
>> hard to
>> > > merge the wrong branch. If the list of commits that comes up doesn't
>> > look
>> > > basically correct, you probably did something wrong-- trying to rebase
>> > onto
>> > > the wrong branch will give you tons of commits, most of which aren't
>> > yours.
>> > >
>> > > I think what you've been doing is fine, it's definitely the right
>> > approach
>> > > if you're doing a merge strategy! I've just ended up gravitating to a
>> > > rebase strategy over the years for the reasons I've mentioned.
>> > >
>> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
>> > > jordan@jordanzimmerman.com> wrote:
>> > >
>> > >> I’ll admit that rebase terrifies me. I’ve f’d up several projects
>> with
>> > it
>> > >> so I can’t even type the letters without breaking into a sweat. "git
>> > rebase
>> > >> -i” is a lot safer, though. Here’s what I’ve been doing - let me
>> know if
>> > >> it’s OK. For branches that are off of CURATOR-3.0, I never merge
>> > master. I
>> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact, should we
>> > have a
>> > >> branch naming scheme to enforce this?
>> > >>
>> > >> -Jordan
>> > >>
>> > >>
>> > >>
>> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (
>> dragonsinth@apache.org)
>> > >> wrote:
>> > >>
>> > >> Correct. When I say "main" branch vs. "feature" branch I just mean
>> the
>> > >> stable branch everyone is working against (3.0 or master) vs. a
>> feature
>> > >> branch where you're actively working.
>> > >>
>> > >> You'll get to a point in development where you'll think "Hey, there
>> are
>> > >> changes on the main branch I'm working against that I really need to
>> > pull
>> > >> into my feature branch." At that point (particularly if you have an
>> svn
>> > >> background) you'll be tempted to merge the main branch into your
>> feature
>> > >> branch. I would suggest not doing that, as it makes the history very
>> > muddy
>> > >> to follow. Instead, my workflow is usually more like this:
>> > >>
>> > >> Suppose I'm working on CURATOR-218. It was originally branched off
>> 3.0,
>> > >> and I want to pull in new changes.
>> > >>
>> > >> git remote update
>> > >> git rebase -i origin/CURATOR-3.0
>> > >>
>> > >> This pulls up an editor that gives me the list of commits to rebase.
>> I
>> > >> would typically exit out of the editor to at this point to accept the
>> > >> commit list, but if I'm so inclined, I'll do things like reorder the
>> > list,
>> > >> or squash commits like like "wip" or "minor reformat" into a more
>> > curated
>> > >> set of logical commits.
>> > >>
>> > >> Once you exit the editor, git goes through and applies each commit,
>> one
>> > at
>> > >> a time, to the head of the target branch. It's like picking up your
>> > commit
>> > >> chain and dumping it at the end of the target branch, as if all your
>> > work
>> > >> had been done against what's now the head of that branch. You'll may
>> > have
>> > >> to fix conflicts along the way, but usually not much more than if you
>> > did
>> > >> it as a merge.
>> > >>
>> > >> I'd encourage us to try this out a couple times and get a feel for
>> the
>> > >> rebase flow. It's a little more to get your head around at first, but
>> > the
>> > >> upside is you end up with really easy to follow commit histories,
>> which
>> > >> makes it way easier to untangle problems later if they crop up.
>> > >>
>> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
>> > >> jordan@jordanzimmerman.com> wrote:
>> > >>
>> > >> > Can you explain this in detail? For me, I have some features that
>> are
>> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master. The
>> true
>> > >> > “master” is Curator 2.x only, right?
>> > >> >
>> > >> > -Jordan
>> > >> >
>> > >> >
>> > >> >
>> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
>> dragonsinth@apache.org
>> > )
>> > >> > wrote:
>> > >> >
>> > >> > BTW: I noticed a couple of new commits
>> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
>> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting
>> > merged
>> > >> > into feature branches. Almost every project I've been on we don't
>> tend
>> > >> to
>> > >> > do that as it leads to confusing history (this isn't just
>> aesthetic,
>> > it
>> > >> > can
>> > >> > get harder for tooling to figure out what happened). If I want to
>> pull
>> > >> > changes from the main branch into my feature branch, I would
>> typically
>> > >> > *rebase* my feature branch against the main branch.
>> > >> >
>> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
>> dragonsinth@apache.org>
>> > >> > wrote:
>> > >> >
>> > >> > > Yeah, 217 & 161 were the first two big things in 3.0.
>> > >> > >
>> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
>> > >> > > jordan@jordanzimmerman.com> wrote:
>> > >> > >
>> > >> > >> OK - Also, is CURATOR-161 complete? The issue is still open in
>> > Jira.
>> > >> > >>
>> > >> > >>
>> > >> > >>
>> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
>> > >> > >> mckenzie.cam@gmail.com) wrote:
>> > >> > >>
>> > >> > >> Yes, I merged it in last week some time.
>> > >> > >>
>> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
>> > >> > >> jordan@jordanzimmerman.com> wrote:
>> > >> > >>
>> > >> > >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
>> > >> > >> >
>> > >> > >> > -Jordan
>> > >> > >> >
>> > >> > >> >
>> > >> > >> >
>> > >> > >>
>> > >> > >
>> > >> > >
>> > >> >
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
>
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
Thanks Mike,
Will give it a spin today some time.
cheers
On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <ma...@cloudera.com> wrote:
> if you're going to tray that, here's what you want to do (assuming command
> line)
>
> git checkout CURATOR-167 # start with the branch that you are changing
> git rebase -i master # rebase the current branch on top of the given branch
>
> On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <mc...@gmail.com>
> wrote:
>
> > Scott,
> > I've been using a similar approach to Jordan given that's what I'm used
> to,
> > but I'm happy to try your approach. I'm going to try and fix up
> CURATOR-167
> > as it will no longer cleanly merge (it's been sitting there a while).
> So, I
> > should rebase master into the CURATOR-167 branch?
> > cheers
> >
> > On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <dr...@apache.org>
> > wrote:
> >
> > > LOL! So sorry to hear that. Yeah, it's definitely possible to mess
> > > things up badly. If I'm doing something particularly risky, I'll just
> > "git
> > > branch original" before I start, so as to leave a branch pointer at my
> > > start point as a safe recovery if it goes south. I also use gitk to
> > > visualize sometimes.
> > >
> > > Another major selling point for rebase (-i) is that it's *really* hard
> to
> > > merge the wrong branch. If the list of commits that comes up doesn't
> > look
> > > basically correct, you probably did something wrong-- trying to rebase
> > onto
> > > the wrong branch will give you tons of commits, most of which aren't
> > yours.
> > >
> > > I think what you've been doing is fine, it's definitely the right
> > approach
> > > if you're doing a merge strategy! I've just ended up gravitating to a
> > > rebase strategy over the years for the reasons I've mentioned.
> > >
> > > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> > > jordan@jordanzimmerman.com> wrote:
> > >
> > >> I’ll admit that rebase terrifies me. I’ve f’d up several projects with
> > it
> > >> so I can’t even type the letters without breaking into a sweat. "git
> > rebase
> > >> -i” is a lot safer, though. Here’s what I’ve been doing - let me know
> if
> > >> it’s OK. For branches that are off of CURATOR-3.0, I never merge
> > master. I
> > >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact, should we
> > have a
> > >> branch naming scheme to enforce this?
> > >>
> > >> -Jordan
> > >>
> > >>
> > >>
> > >> On August 24, 2015 at 11:30:50 AM, Scott Blum (dragonsinth@apache.org
> )
> > >> wrote:
> > >>
> > >> Correct. When I say "main" branch vs. "feature" branch I just mean the
> > >> stable branch everyone is working against (3.0 or master) vs. a
> feature
> > >> branch where you're actively working.
> > >>
> > >> You'll get to a point in development where you'll think "Hey, there
> are
> > >> changes on the main branch I'm working against that I really need to
> > pull
> > >> into my feature branch." At that point (particularly if you have an
> svn
> > >> background) you'll be tempted to merge the main branch into your
> feature
> > >> branch. I would suggest not doing that, as it makes the history very
> > muddy
> > >> to follow. Instead, my workflow is usually more like this:
> > >>
> > >> Suppose I'm working on CURATOR-218. It was originally branched off
> 3.0,
> > >> and I want to pull in new changes.
> > >>
> > >> git remote update
> > >> git rebase -i origin/CURATOR-3.0
> > >>
> > >> This pulls up an editor that gives me the list of commits to rebase. I
> > >> would typically exit out of the editor to at this point to accept the
> > >> commit list, but if I'm so inclined, I'll do things like reorder the
> > list,
> > >> or squash commits like like "wip" or "minor reformat" into a more
> > curated
> > >> set of logical commits.
> > >>
> > >> Once you exit the editor, git goes through and applies each commit,
> one
> > at
> > >> a time, to the head of the target branch. It's like picking up your
> > commit
> > >> chain and dumping it at the end of the target branch, as if all your
> > work
> > >> had been done against what's now the head of that branch. You'll may
> > have
> > >> to fix conflicts along the way, but usually not much more than if you
> > did
> > >> it as a merge.
> > >>
> > >> I'd encourage us to try this out a couple times and get a feel for the
> > >> rebase flow. It's a little more to get your head around at first, but
> > the
> > >> upside is you end up with really easy to follow commit histories,
> which
> > >> makes it way easier to untangle problems later if they crop up.
> > >>
> > >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> > >> jordan@jordanzimmerman.com> wrote:
> > >>
> > >> > Can you explain this in detail? For me, I have some features that
> are
> > >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master. The
> true
> > >> > “master” is Curator 2.x only, right?
> > >> >
> > >> > -Jordan
> > >> >
> > >> >
> > >> >
> > >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (
> dragonsinth@apache.org
> > )
> > >> > wrote:
> > >> >
> > >> > BTW: I noticed a couple of new commits
> > >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> > >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting
> > merged
> > >> > into feature branches. Almost every project I've been on we don't
> tend
> > >> to
> > >> > do that as it leads to confusing history (this isn't just aesthetic,
> > it
> > >> > can
> > >> > get harder for tooling to figure out what happened). If I want to
> pull
> > >> > changes from the main branch into my feature branch, I would
> typically
> > >> > *rebase* my feature branch against the main branch.
> > >> >
> > >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <
> dragonsinth@apache.org>
> > >> > wrote:
> > >> >
> > >> > > Yeah, 217 & 161 were the first two big things in 3.0.
> > >> > >
> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> > >> > > jordan@jordanzimmerman.com> wrote:
> > >> > >
> > >> > >> OK - Also, is CURATOR-161 complete? The issue is still open in
> > Jira.
> > >> > >>
> > >> > >>
> > >> > >>
> > >> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> > >> > >> mckenzie.cam@gmail.com) wrote:
> > >> > >>
> > >> > >> Yes, I merged it in last week some time.
> > >> > >>
> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> > >> > >> jordan@jordanzimmerman.com> wrote:
> > >> > >>
> > >> > >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
> > >> > >> >
> > >> > >> > -Jordan
> > >> > >> >
> > >> > >> >
> > >> > >> >
> > >> > >>
> > >> > >
> > >> > >
> > >> >
> > >> >
> > >>
> > >
> > >
> >
>
Re: CURATOR-217?
Posted by Mike Drob <ma...@cloudera.com>.
if you're going to tray that, here's what you want to do (assuming command
line)
git checkout CURATOR-167 # start with the branch that you are changing
git rebase -i master # rebase the current branch on top of the given branch
On Mon, Aug 24, 2015 at 5:07 PM, Cameron McKenzie <mc...@gmail.com>
wrote:
> Scott,
> I've been using a similar approach to Jordan given that's what I'm used to,
> but I'm happy to try your approach. I'm going to try and fix up CURATOR-167
> as it will no longer cleanly merge (it's been sitting there a while). So, I
> should rebase master into the CURATOR-167 branch?
> cheers
>
> On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <dr...@apache.org>
> wrote:
>
> > LOL! So sorry to hear that. Yeah, it's definitely possible to mess
> > things up badly. If I'm doing something particularly risky, I'll just
> "git
> > branch original" before I start, so as to leave a branch pointer at my
> > start point as a safe recovery if it goes south. I also use gitk to
> > visualize sometimes.
> >
> > Another major selling point for rebase (-i) is that it's *really* hard to
> > merge the wrong branch. If the list of commits that comes up doesn't
> look
> > basically correct, you probably did something wrong-- trying to rebase
> onto
> > the wrong branch will give you tons of commits, most of which aren't
> yours.
> >
> > I think what you've been doing is fine, it's definitely the right
> approach
> > if you're doing a merge strategy! I've just ended up gravitating to a
> > rebase strategy over the years for the reasons I've mentioned.
> >
> > On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> > jordan@jordanzimmerman.com> wrote:
> >
> >> I’ll admit that rebase terrifies me. I’ve f’d up several projects with
> it
> >> so I can’t even type the letters without breaking into a sweat. "git
> rebase
> >> -i” is a lot safer, though. Here’s what I’ve been doing - let me know if
> >> it’s OK. For branches that are off of CURATOR-3.0, I never merge
> master. I
> >> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact, should we
> have a
> >> branch naming scheme to enforce this?
> >>
> >> -Jordan
> >>
> >>
> >>
> >> On August 24, 2015 at 11:30:50 AM, Scott Blum (dragonsinth@apache.org)
> >> wrote:
> >>
> >> Correct. When I say "main" branch vs. "feature" branch I just mean the
> >> stable branch everyone is working against (3.0 or master) vs. a feature
> >> branch where you're actively working.
> >>
> >> You'll get to a point in development where you'll think "Hey, there are
> >> changes on the main branch I'm working against that I really need to
> pull
> >> into my feature branch." At that point (particularly if you have an svn
> >> background) you'll be tempted to merge the main branch into your feature
> >> branch. I would suggest not doing that, as it makes the history very
> muddy
> >> to follow. Instead, my workflow is usually more like this:
> >>
> >> Suppose I'm working on CURATOR-218. It was originally branched off 3.0,
> >> and I want to pull in new changes.
> >>
> >> git remote update
> >> git rebase -i origin/CURATOR-3.0
> >>
> >> This pulls up an editor that gives me the list of commits to rebase. I
> >> would typically exit out of the editor to at this point to accept the
> >> commit list, but if I'm so inclined, I'll do things like reorder the
> list,
> >> or squash commits like like "wip" or "minor reformat" into a more
> curated
> >> set of logical commits.
> >>
> >> Once you exit the editor, git goes through and applies each commit, one
> at
> >> a time, to the head of the target branch. It's like picking up your
> commit
> >> chain and dumping it at the end of the target branch, as if all your
> work
> >> had been done against what's now the head of that branch. You'll may
> have
> >> to fix conflicts along the way, but usually not much more than if you
> did
> >> it as a merge.
> >>
> >> I'd encourage us to try this out a couple times and get a feel for the
> >> rebase flow. It's a little more to get your head around at first, but
> the
> >> upside is you end up with really easy to follow commit histories, which
> >> makes it way easier to untangle problems later if they crop up.
> >>
> >> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> >> jordan@jordanzimmerman.com> wrote:
> >>
> >> > Can you explain this in detail? For me, I have some features that are
> >> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master. The true
> >> > “master” is Curator 2.x only, right?
> >> >
> >> > -Jordan
> >> >
> >> >
> >> >
> >> > On August 24, 2015 at 11:10:08 AM, Scott Blum (dragonsinth@apache.org
> )
> >> > wrote:
> >> >
> >> > BTW: I noticed a couple of new commits
> >> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> >> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting
> merged
> >> > into feature branches. Almost every project I've been on we don't tend
> >> to
> >> > do that as it leads to confusing history (this isn't just aesthetic,
> it
> >> > can
> >> > get harder for tooling to figure out what happened). If I want to pull
> >> > changes from the main branch into my feature branch, I would typically
> >> > *rebase* my feature branch against the main branch.
> >> >
> >> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <dr...@apache.org>
> >> > wrote:
> >> >
> >> > > Yeah, 217 & 161 were the first two big things in 3.0.
> >> > >
> >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> >> > > jordan@jordanzimmerman.com> wrote:
> >> > >
> >> > >> OK - Also, is CURATOR-161 complete? The issue is still open in
> Jira.
> >> > >>
> >> > >>
> >> > >>
> >> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> >> > >> mckenzie.cam@gmail.com) wrote:
> >> > >>
> >> > >> Yes, I merged it in last week some time.
> >> > >>
> >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> >> > >> jordan@jordanzimmerman.com> wrote:
> >> > >>
> >> > >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
> >> > >> >
> >> > >> > -Jordan
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >>
> >> > >
> >> > >
> >> >
> >> >
> >>
> >
> >
>
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
Scott,
I've been using a similar approach to Jordan given that's what I'm used to,
but I'm happy to try your approach. I'm going to try and fix up CURATOR-167
as it will no longer cleanly merge (it's been sitting there a while). So, I
should rebase master into the CURATOR-167 branch?
cheers
On Tue, Aug 25, 2015 at 2:55 AM, Scott Blum <dr...@apache.org> wrote:
> LOL! So sorry to hear that. Yeah, it's definitely possible to mess
> things up badly. If I'm doing something particularly risky, I'll just "git
> branch original" before I start, so as to leave a branch pointer at my
> start point as a safe recovery if it goes south. I also use gitk to
> visualize sometimes.
>
> Another major selling point for rebase (-i) is that it's *really* hard to
> merge the wrong branch. If the list of commits that comes up doesn't look
> basically correct, you probably did something wrong-- trying to rebase onto
> the wrong branch will give you tons of commits, most of which aren't yours.
>
> I think what you've been doing is fine, it's definitely the right approach
> if you're doing a merge strategy! I've just ended up gravitating to a
> rebase strategy over the years for the reasons I've mentioned.
>
> On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> I’ll admit that rebase terrifies me. I’ve f’d up several projects with it
>> so I can’t even type the letters without breaking into a sweat. "git rebase
>> -i” is a lot safer, though. Here’s what I’ve been doing - let me know if
>> it’s OK. For branches that are off of CURATOR-3.0, I never merge master. I
>> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact, should we have a
>> branch naming scheme to enforce this?
>>
>> -Jordan
>>
>>
>>
>> On August 24, 2015 at 11:30:50 AM, Scott Blum (dragonsinth@apache.org)
>> wrote:
>>
>> Correct. When I say "main" branch vs. "feature" branch I just mean the
>> stable branch everyone is working against (3.0 or master) vs. a feature
>> branch where you're actively working.
>>
>> You'll get to a point in development where you'll think "Hey, there are
>> changes on the main branch I'm working against that I really need to pull
>> into my feature branch." At that point (particularly if you have an svn
>> background) you'll be tempted to merge the main branch into your feature
>> branch. I would suggest not doing that, as it makes the history very muddy
>> to follow. Instead, my workflow is usually more like this:
>>
>> Suppose I'm working on CURATOR-218. It was originally branched off 3.0,
>> and I want to pull in new changes.
>>
>> git remote update
>> git rebase -i origin/CURATOR-3.0
>>
>> This pulls up an editor that gives me the list of commits to rebase. I
>> would typically exit out of the editor to at this point to accept the
>> commit list, but if I'm so inclined, I'll do things like reorder the list,
>> or squash commits like like "wip" or "minor reformat" into a more curated
>> set of logical commits.
>>
>> Once you exit the editor, git goes through and applies each commit, one at
>> a time, to the head of the target branch. It's like picking up your commit
>> chain and dumping it at the end of the target branch, as if all your work
>> had been done against what's now the head of that branch. You'll may have
>> to fix conflicts along the way, but usually not much more than if you did
>> it as a merge.
>>
>> I'd encourage us to try this out a couple times and get a feel for the
>> rebase flow. It's a little more to get your head around at first, but the
>> upside is you end up with really easy to follow commit histories, which
>> makes it way easier to untangle problems later if they crop up.
>>
>> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>> > Can you explain this in detail? For me, I have some features that are
>> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master. The true
>> > “master” is Curator 2.x only, right?
>> >
>> > -Jordan
>> >
>> >
>> >
>> > On August 24, 2015 at 11:10:08 AM, Scott Blum (dragonsinth@apache.org)
>> > wrote:
>> >
>> > BTW: I noticed a couple of new commits
>> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
>> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting merged
>> > into feature branches. Almost every project I've been on we don't tend
>> to
>> > do that as it leads to confusing history (this isn't just aesthetic, it
>> > can
>> > get harder for tooling to figure out what happened). If I want to pull
>> > changes from the main branch into my feature branch, I would typically
>> > *rebase* my feature branch against the main branch.
>> >
>> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <dr...@apache.org>
>> > wrote:
>> >
>> > > Yeah, 217 & 161 were the first two big things in 3.0.
>> > >
>> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
>> > > jordan@jordanzimmerman.com> wrote:
>> > >
>> > >> OK - Also, is CURATOR-161 complete? The issue is still open in Jira.
>> > >>
>> > >>
>> > >>
>> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
>> > >> mckenzie.cam@gmail.com) wrote:
>> > >>
>> > >> Yes, I merged it in last week some time.
>> > >>
>> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
>> > >> jordan@jordanzimmerman.com> wrote:
>> > >>
>> > >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
>> > >> >
>> > >> > -Jordan
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >
>> > >
>> >
>> >
>>
>
>
Re: CURATOR-217?
Posted by Scott Blum <dr...@apache.org>.
LOL! So sorry to hear that. Yeah, it's definitely possible to mess things
up badly. If I'm doing something particularly risky, I'll just "git branch
original" before I start, so as to leave a branch pointer at my start point
as a safe recovery if it goes south. I also use gitk to visualize
sometimes.
Another major selling point for rebase (-i) is that it's *really* hard to
merge the wrong branch. If the list of commits that comes up doesn't look
basically correct, you probably did something wrong-- trying to rebase onto
the wrong branch will give you tons of commits, most of which aren't yours.
I think what you've been doing is fine, it's definitely the right approach
if you're doing a merge strategy! I've just ended up gravitating to a
rebase strategy over the years for the reasons I've mentioned.
On Mon, Aug 24, 2015 at 12:43 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> I’ll admit that rebase terrifies me. I’ve f’d up several projects with it
> so I can’t even type the letters without breaking into a sweat. "git rebase
> -i” is a lot safer, though. Here’s what I’ve been doing - let me know if
> it’s OK. For branches that are off of CURATOR-3.0, I never merge master. I
> only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact, should we have a
> branch naming scheme to enforce this?
>
> -Jordan
>
>
>
> On August 24, 2015 at 11:30:50 AM, Scott Blum (dragonsinth@apache.org)
> wrote:
>
> Correct. When I say "main" branch vs. "feature" branch I just mean the
> stable branch everyone is working against (3.0 or master) vs. a feature
> branch where you're actively working.
>
> You'll get to a point in development where you'll think "Hey, there are
> changes on the main branch I'm working against that I really need to pull
> into my feature branch." At that point (particularly if you have an svn
> background) you'll be tempted to merge the main branch into your feature
> branch. I would suggest not doing that, as it makes the history very muddy
> to follow. Instead, my workflow is usually more like this:
>
> Suppose I'm working on CURATOR-218. It was originally branched off 3.0,
> and I want to pull in new changes.
>
> git remote update
> git rebase -i origin/CURATOR-3.0
>
> This pulls up an editor that gives me the list of commits to rebase. I
> would typically exit out of the editor to at this point to accept the
> commit list, but if I'm so inclined, I'll do things like reorder the list,
> or squash commits like like "wip" or "minor reformat" into a more curated
> set of logical commits.
>
> Once you exit the editor, git goes through and applies each commit, one at
> a time, to the head of the target branch. It's like picking up your commit
> chain and dumping it at the end of the target branch, as if all your work
> had been done against what's now the head of that branch. You'll may have
> to fix conflicts along the way, but usually not much more than if you did
> it as a merge.
>
> I'd encourage us to try this out a couple times and get a feel for the
> rebase flow. It's a little more to get your head around at first, but the
> upside is you end up with really easy to follow commit histories, which
> makes it way easier to untangle problems later if they crop up.
>
> On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
> > Can you explain this in detail? For me, I have some features that are
> > 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master. The true
> > “master” is Curator 2.x only, right?
> >
> > -Jordan
> >
> >
> >
> > On August 24, 2015 at 11:10:08 AM, Scott Blum (dragonsinth@apache.org)
> > wrote:
> >
> > BTW: I noticed a couple of new commits
> > (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> > & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting merged
> > into feature branches. Almost every project I've been on we don't tend to
> > do that as it leads to confusing history (this isn't just aesthetic, it
> > can
> > get harder for tooling to figure out what happened). If I want to pull
> > changes from the main branch into my feature branch, I would typically
> > *rebase* my feature branch against the main branch.
> >
> > On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <dr...@apache.org>
> > wrote:
> >
> > > Yeah, 217 & 161 were the first two big things in 3.0.
> > >
> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> > > jordan@jordanzimmerman.com> wrote:
> > >
> > >> OK - Also, is CURATOR-161 complete? The issue is still open in Jira.
> > >>
> > >>
> > >>
> > >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> > >> mckenzie.cam@gmail.com) wrote:
> > >>
> > >> Yes, I merged it in last week some time.
> > >>
> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> > >> jordan@jordanzimmerman.com> wrote:
> > >>
> > >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
> > >> >
> > >> > -Jordan
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> >
> >
>
Re: CURATOR-217?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
I’ll admit that rebase terrifies me. I’ve f’d up several projects with it so I can’t even type the letters without breaking into a sweat. "git rebase -i” is a lot safer, though. Here’s what I’ve been doing - let me know if it’s OK. For branches that are off of CURATOR-3.0, I never merge master. I only merge CURATOR-3.0: “git merge CURATOR-3.0”. In fact, should we have a branch naming scheme to enforce this?
-Jordan
On August 24, 2015 at 11:30:50 AM, Scott Blum (dragonsinth@apache.org) wrote:
Correct. When I say "main" branch vs. "feature" branch I just mean the
stable branch everyone is working against (3.0 or master) vs. a feature
branch where you're actively working.
You'll get to a point in development where you'll think "Hey, there are
changes on the main branch I'm working against that I really need to pull
into my feature branch." At that point (particularly if you have an svn
background) you'll be tempted to merge the main branch into your feature
branch. I would suggest not doing that, as it makes the history very muddy
to follow. Instead, my workflow is usually more like this:
Suppose I'm working on CURATOR-218. It was originally branched off 3.0,
and I want to pull in new changes.
git remote update
git rebase -i origin/CURATOR-3.0
This pulls up an editor that gives me the list of commits to rebase. I
would typically exit out of the editor to at this point to accept the
commit list, but if I'm so inclined, I'll do things like reorder the list,
or squash commits like like "wip" or "minor reformat" into a more curated
set of logical commits.
Once you exit the editor, git goes through and applies each commit, one at
a time, to the head of the target branch. It's like picking up your commit
chain and dumping it at the end of the target branch, as if all your work
had been done against what's now the head of that branch. You'll may have
to fix conflicts along the way, but usually not much more than if you did
it as a merge.
I'd encourage us to try this out a couple times and get a feel for the
rebase flow. It's a little more to get your head around at first, but the
upside is you end up with really easy to follow commit histories, which
makes it way easier to untangle problems later if they crop up.
On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Can you explain this in detail? For me, I have some features that are
> 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master. The true
> “master” is Curator 2.x only, right?
>
> -Jordan
>
>
>
> On August 24, 2015 at 11:10:08 AM, Scott Blum (dragonsinth@apache.org)
> wrote:
>
> BTW: I noticed a couple of new commits
> (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting merged
> into feature branches. Almost every project I've been on we don't tend to
> do that as it leads to confusing history (this isn't just aesthetic, it
> can
> get harder for tooling to figure out what happened). If I want to pull
> changes from the main branch into my feature branch, I would typically
> *rebase* my feature branch against the main branch.
>
> On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <dr...@apache.org>
> wrote:
>
> > Yeah, 217 & 161 were the first two big things in 3.0.
> >
> > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> > jordan@jordanzimmerman.com> wrote:
> >
> >> OK - Also, is CURATOR-161 complete? The issue is still open in Jira.
> >>
> >>
> >>
> >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> >> mckenzie.cam@gmail.com) wrote:
> >>
> >> Yes, I merged it in last week some time.
> >>
> >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> >> jordan@jordanzimmerman.com> wrote:
> >>
> >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
> >> >
> >> > -Jordan
> >> >
> >> >
> >> >
> >>
> >
> >
>
>
Re: CURATOR-217?
Posted by Scott Blum <dr...@apache.org>.
Correct. When I say "main" branch vs. "feature" branch I just mean the
stable branch everyone is working against (3.0 or master) vs. a feature
branch where you're actively working.
You'll get to a point in development where you'll think "Hey, there are
changes on the main branch I'm working against that I really need to pull
into my feature branch." At that point (particularly if you have an svn
background) you'll be tempted to merge the main branch into your feature
branch. I would suggest not doing that, as it makes the history very muddy
to follow. Instead, my workflow is usually more like this:
Suppose I'm working on CURATOR-218. It was originally branched off 3.0,
and I want to pull in new changes.
git remote update
git rebase -i origin/CURATOR-3.0
This pulls up an editor that gives me the list of commits to rebase. I
would typically exit out of the editor to at this point to accept the
commit list, but if I'm so inclined, I'll do things like reorder the list,
or squash commits like like "wip" or "minor reformat" into a more curated
set of logical commits.
Once you exit the editor, git goes through and applies each commit, one at
a time, to the head of the target branch. It's like picking up your commit
chain and dumping it at the end of the target branch, as if all your work
had been done against what's now the head of that branch. You'll may have
to fix conflicts along the way, but usually not much more than if you did
it as a merge.
I'd encourage us to try this out a couple times and get a feel for the
rebase flow. It's a little more to get your head around at first, but the
upside is you end up with really easy to follow commit histories, which
makes it way easier to untangle problems later if they crop up.
On Mon, Aug 24, 2015 at 12:17 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Can you explain this in detail? For me, I have some features that are
> 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master. The true
> “master” is Curator 2.x only, right?
>
> -Jordan
>
>
>
> On August 24, 2015 at 11:10:08 AM, Scott Blum (dragonsinth@apache.org)
> wrote:
>
> BTW: I noticed a couple of new commits
> (ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
> & 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting merged
> into feature branches. Almost every project I've been on we don't tend to
> do that as it leads to confusing history (this isn't just aesthetic, it
> can
> get harder for tooling to figure out what happened). If I want to pull
> changes from the main branch into my feature branch, I would typically
> *rebase* my feature branch against the main branch.
>
> On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <dr...@apache.org>
> wrote:
>
> > Yeah, 217 & 161 were the first two big things in 3.0.
> >
> > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> > jordan@jordanzimmerman.com> wrote:
> >
> >> OK - Also, is CURATOR-161 complete? The issue is still open in Jira.
> >>
> >>
> >>
> >> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> >> mckenzie.cam@gmail.com) wrote:
> >>
> >> Yes, I merged it in last week some time.
> >>
> >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> >> jordan@jordanzimmerman.com> wrote:
> >>
> >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
> >> >
> >> > -Jordan
> >> >
> >> >
> >> >
> >>
> >
> >
>
>
Re: CURATOR-217?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
Can you explain this in detail? For me, I have some features that are 3.0.0 based so I’m treating CURATOR-3.0 as a kind of master. The true “master” is Curator 2.x only, right?
-Jordan
On August 24, 2015 at 11:10:08 AM, Scott Blum (dragonsinth@apache.org) wrote:
BTW: I noticed a couple of new commits
(ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
& 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting merged
into feature branches. Almost every project I've been on we don't tend to
do that as it leads to confusing history (this isn't just aesthetic, it can
get harder for tooling to figure out what happened). If I want to pull
changes from the main branch into my feature branch, I would typically
*rebase* my feature branch against the main branch.
On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <dr...@apache.org> wrote:
> Yeah, 217 & 161 were the first two big things in 3.0.
>
> On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> OK - Also, is CURATOR-161 complete? The issue is still open in Jira.
>>
>>
>>
>> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
>> mckenzie.cam@gmail.com) wrote:
>>
>> Yes, I merged it in last week some time.
>>
>> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
>> >
>> > -Jordan
>> >
>> >
>> >
>>
>
>
Re: CURATOR-217?
Posted by Scott Blum <dr...@apache.org>.
BTW: I noticed a couple of new commits
(ba4b5d8cb1f9733d3901b0b619528454d3dbf8c8
& 2343daf29388566b0efa0b0a2ad21574fb534a27) where 3.0 is getting merged
into feature branches. Almost every project I've been on we don't tend to
do that as it leads to confusing history (this isn't just aesthetic, it can
get harder for tooling to figure out what happened). If I want to pull
changes from the main branch into my feature branch, I would typically
*rebase* my feature branch against the main branch.
On Mon, Aug 24, 2015 at 12:05 PM, Scott Blum <dr...@apache.org> wrote:
> Yeah, 217 & 161 were the first two big things in 3.0.
>
> On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
>> OK - Also, is CURATOR-161 complete? The issue is still open in Jira.
>>
>>
>>
>> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
>> mckenzie.cam@gmail.com) wrote:
>>
>> Yes, I merged it in last week some time.
>>
>> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
>> jordan@jordanzimmerman.com> wrote:
>>
>> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
>> >
>> > -Jordan
>> >
>> >
>> >
>>
>
>
Re: CURATOR-217?
Posted by Scott Blum <dr...@apache.org>.
Yeah, 217 & 161 were the first two big things in 3.0.
On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> OK - Also, is CURATOR-161 complete? The issue is still open in Jira.
>
>
>
> On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (
> mckenzie.cam@gmail.com) wrote:
>
> Yes, I merged it in last week some time.
>
> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
> jordan@jordanzimmerman.com> wrote:
>
> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
> >
> > -Jordan
> >
> >
> >
>
Re: CURATOR-217?
Posted by Jordan Zimmerman <jo...@jordanzimmerman.com>.
OK - Also, is CURATOR-161 complete? The issue is still open in Jira.
On August 24, 2015 at 12:47:21 AM, Cameron McKenzie (mckenzie.cam@gmail.com) wrote:
Yes, I merged it in last week some time.
On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
>
> -Jordan
>
>
>
Re: CURATOR-217?
Posted by Cameron McKenzie <mc...@gmail.com>.
Yes, I merged it in last week some time.
On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:
> Scott, did CURATOR-217 get merged into the new CURATOR-3.0?
>
> -Jordan
>
>
>