curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Blum <dragonsi...@gmail.com>
Subject Re: CURATOR-217?
Date Tue, 25 Aug 2015 15:00:48 GMT
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
> > > > > >> > >> > >> >
> > > > > >> > >> > >> >
> > > > > >> > >> > >> >
> > > > > >> > >> > >>
> > > > > >> > >> > >
> > > > > >> > >> > >
> > > > > >> > >> >
> > > > > >> > >> >
> > > > > >> > >>
> > > > > >> > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

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