3

For some reason, running a git rebase is suddenly not rebasing my entire branch and I cannot imagine why. What I have before rebase is the following:

enter image description here



What I have after running git rebase develop is this:

enter image description here

Notice that none of the commits from the branch came along in the rebase. At this point I have to run a git reset --hard on the last commit of what is now a headless branch to get things back in order.

Strangely enough, if I create additional commits on the feature-relationalSurveys branch beyond those shown in the screenshot and then rebase, all additional commits will come along in the rebase. It's like git doesn't know where the branch actually starts. I've never seen this happen before and I have no idea what's causing it or how to fix it. Any ideas?

Improve this question
1
  • Could you show develop prior to the rebase please? Commented Aug 21, 2015 at 21:45

1 Answer 1

Reset to default
2

I'm going to take a guess based on the information provided. Either A) your visualization tool is broken or B) develop already contained all the content of feature-relationalSurveys. You can test A by trying another visualization tool like git log --decorate --graph.

Lemme explain B. The key pieces of information are...

  • feature-relationalSurveys is at a merge point, rebase should not merge.
  • feature-relationalSurveys is at the same point as develop.
    • Even more strange, it's at the same point as origin/develop.
  • None of the commits in feature-relationalSurveys are at its tip after the rebase.
    • I presume those commits are deeper in the history.

The only way I can think this happened is if you had something like this...

2 [develop] | 1 | A' [feature-relationalSurveys] A | | B' B | | C' C / |/ D

I'm not exactly sure how you'd get into that state, maybe through a weird merge or rebase, but there you go. When Git goes to rebase feature-relationalSurveys onto develop it notices C''s content is the same as C, so it skips it. B''s content is the same as B, so it skips it. A' and A are the same, skipped. There's no differing content left, so it just plops feature-relationalSurveys where develop is.

2 [develop] [feature-relationalSurveys] | 1 | A | B | C | D

None of feature-relationalSurveys changes are visible at the tip of develop because they're buried earlier in develop's history.

That's my best guess, and one only you can verify. It would help to show the state of develop prior to the rebase.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

You nailed it with B, totally my own lack of attention. I'm guessing that I didn't switch to develop when creating a 2nd feature branch; instead I branched off of an existing feature branch that I wasn't ready to merge in. When I rebased the 2nd feature branch onto develop the commits from the 1st came along for the ride and subsequently got merged in. Then when trying to rebase the 1st feature branch onto develop, if no new commits have been made, there's nothing to rebase because the 2nd branch based on the 1st already did the work. Dumb move on my part, thanks for pointing it out.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.