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 Mon, 24 Aug 2015 22:48:03 GMT
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