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 <[email protected]> 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 <[email protected]> > wrote: > > > Thanks Mike, > > Will give it a spin today some time. > > cheers > > > > On Tue, Aug 25, 2015 at 8:36 AM, Mike Drob <[email protected]> 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 < > [email protected] > >> > > >> 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 <[email protected]> > >> > 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 < > >> > > [email protected]> 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 ( > >> [email protected]) > >> > >> 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 < > >> > >> [email protected]> 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 ( > >> [email protected] > >> > ) > >> > >> > 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 < > >> [email protected]> > >> > >> > wrote: > >> > >> > > >> > >> > > Yeah, 217 & 161 were the first two big things in 3.0. > >> > >> > > > >> > >> > > On Mon, Aug 24, 2015 at 9:53 AM, Jordan Zimmerman < > >> > >> > > [email protected]> 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 ( > >> > >> > >> [email protected]) wrote: > >> > >> > >> > >> > >> > >> Yes, I merged it in last week some time. > >> > >> > >> > >> > >> > >> On Mon, Aug 24, 2015 at 3:25 PM, Jordan Zimmerman < > >> > >> > >> [email protected]> wrote: > >> > >> > >> > >> > >> > >> > Scott, did CURATOR-217 get merged into the new CURATOR-3.0? > >> > >> > >> > > >> > >> > >> > -Jordan > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > > >> > >> > >> > >> > >> > > > >> > >> > > > >> > >> > > >> > >> > > >> > >> > >> > > > >> > > > >> > > >> > > > > >
