CODEWITHSUNDEEP
git
Daniel Hilgarth
Daniel Hilgarth

Reputation: 174279

git rebase mixes commits

I have a very strange problem: I have two separate branches and I am doing a simple git rebase --onto branchA tagOnMaster. This is done via a script that used to work perfectly on my old 32 bit machine. Now I switched to a new 64 bit machine and it stops working correctly.
It looks like git mixes commits.
For example, I have two consecutive commits with the first commit changing files a and b and the second commit changing filec. Now, the rebase creates the first commit correctly, but the second commit contains the changes to file c and a revert of the changes in the first commit. This reverted changes however somehow are left behind on the disk and cause problems in the third commit.

I think some images will show better what happens:

First original commit which just changes a space: First original commit

Second original commit which only adds two new files: Second original commit

The first rebased commit - this one is correct: First rebased commit

But now it is getting strange: The second rebased commit contains the reverse of the first rebased commit in addition to the two newly added files: Second rebased commit

After that second commit the rebase failes to continue with this message:

Database/Scripts/Versions/2.0.0/PKG_BODIES/normalinvoices.sql: needs update
You must edit all merge conflicts and then mark them as resolved using git add

And a look at the local changes reveals that the change from commit 1 is there again: unstaged changes

I really would appreciate any insights into this.
Is this a known bug? A feature?! Am I doing something wrong? Is it possible that the corporate anti-virus program somehow locks the files and thus messes everything up? But I can't see how an anti-virus program leads to a file being there earlier than it should...
And most importantly: How to get my rebase working again?

Upvotes: 4

Views: 610

Answers (1)

Eugene Sajine
Eugene Sajine

Reputation: 8200

Your problem is that you're using rebase --onto which i don't see necessity for. It would be helpful to see screenshot of "gitk --all &" and know what do you want as the result of this operation.

Rebase --onto is a command that performs a move of part of the branch to the new base.

from git-rebase docs:

Here is how you would transplant a topic branch based on one branch to another, to pretend that you forked the topic branch from the latter branch, using rebase --onto.

First let’s assume your topic is based on branch next. For example, a feature developed in topic depends on some functionality which is found in next.

o---o---o---o---o  master
     \
      o---o---o---o---o  next
                       \
                        o---o---o  topic

We want to make topic forked from branch master; for example, because the functionality on which topic depends was merged into the more stable master branch. We want our tree to look like this:

o---o---o---o---o  master
    |            \
    |             o'--o'--o'  topic
     \
      o---o---o---o---o  next

We can get this using the following command:

git rebase --onto master next topic

...

In your case the last value is omitted therefore HEAD is used by default. That is causing you problems. I think you have confused the syntax of "rebase --onto" with a shorthand used for simple rebase:

git rebase master topic

this last command actually means:

git checkout topic # switch to topic branch
git rebase master # rebase topic branch on master

Hope that helps!

Upvotes: 2

Related Questions