curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cameron McKenzie <mckenzie....@gmail.com>
Subject Re: CURATOR-217?
Date Tue, 25 Aug 2015 01:37:51 GMT
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
>> > >> > >> >
>> > >> > >> >
>> > >> > >> >
>> > >> > >>
>> > >> > >
>> > >> > >
>> > >> >
>> > >> >
>> > >>
>> > >
>> > >
>> >
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message