curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Drob <mad...@cloudera.com>
Subject Re: CURATOR-217?
Date Tue, 25 Aug 2015 03:00:17 GMT
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
> >> > >> > >> >
> >> > >> > >> >
> >> > >> > >> >
> >> > >> > >>
> >> > >> > >
> >> > >> > >
> >> > >> >
> >> > >> >
> >> > >>
> >> > >
> >> > >
> >> >
> >>
> >
> >
>

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