git p4 rebase fails if changes made to depot

Question

I recently set up a git p4 clone for my main c# project at work. I'm doing the following:

• git checkout -b newbranch
• git p4 rebase (make sure branch is up to date with depot)
• make changes
• git commit -a
• make more changes
• git commit -a
• ready to push files into p4 depot

At this point, if there haven't been any changes in the project's depot path since I started my branch, i'm fine to do a

• git p4 rebase
• git p4 submit

and everything goes just fine. However, if there have been changes in the depot, when I run 'git p4 rebase', it applies the stuff in the depot, then when it tries to re-apply my commits, it errors out, saying "local changes would be overwritten by merge". It then proceeds to list all of the files that I have already committed, telling me that I should commit or stash them. The strange thing is that if I run 'git status', no files show up whatsoever. What is going on here?

The only thing that I've been able to figure out to make it work is to do the following:

• git rebase -i HEAD~{number of commit since last depot change}
• git stash
• git p4 rebase
• git stash pop
• git p4 submit

But I'm not a big fan of that either, because now my commit history is lost - I just end up with one monster commit. This isn't so bad as far as the p4 depot is concerned (heck, that's what I want in the end), but I still want my local Git commits to be visible, otherwise I lost a lot of the value in using Git.

It might be worth mentioning that Git also shows a couple whitespace warnings before it throws the final error... but they are all prefixed with "warning:", so I figure that's not the root cause.

Answer 1

Are your new changes based on the original p4/master branch?

i.e. did you do:

$ git checkout -b my_new_branch p4/master
hack
$ git commit -m 'somechange' -a
hack some more
$ git commit -m 'another change' -a
$ git p4 rebase

You should have your new changes based on p4/master, or it won't work the magic.