Menu
I'm using git svn to work with a client who has an svn repository (our stuff is in github).
So I follow the instructions and do a git svn rebase and then git svn dcommit
That worked the very first time, but ever since then rebasing always conflicts on almost every commit. It seems like it doesn't realize which commits are mine, and complains that things are conflicting. Every time I have to git rebase --skip my way through until it passes those and successfully applies my latest commits. It never figures out where I was the last time I did a rebase (which I believe is what is supposed to happen).
First of all... why? Then can I get around this somehow?
First, rewinding head to replay your work on top of it...
Applying: Deleting their old build management stuff as its pretty crappy. Will re-build at some point.
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: Added some error checking around Android specific calls
Using index info to reconstruct a base tree...
<stdin>:16: space before tab in indent.
Android.hideKeyboard();
<stdin>:31: space before tab in indent.
Android.launchNewAccount();
warning: 2 lines add whitespace errors.
Falling back to patching base and 3-way merge...
CONFLICT (modify/delete): src/LoginForm.js deleted in HEAD and modified in Added some error checking around Android specific calls. Version Added some error checking around Android specific calls of src/LoginForm.js left in tree.
Auto-merging src/ChildPanel.js
CONFLICT (content): Merge conflict in src/ChildPanel.js
Failed to merge in the changes.
Patch failed at 0002 Added some error checking around Android specific calls
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".
236
When you perform a git rebase operation, you're typically moving commits around. Because of this, you might get into a situation where a merge conflict is introduced. That means that two of your commits modified the same line in the same file, and Git doesn't know which change to apply.
The purpose of rebase is make your commits look as if they were changes to the branch you rebase onto. So the most logical way is to incorporate merge conflicts into these commits. No additional commits is required thus. Merge is different, because it's an explicit action of merging diverged branches together.
The golden rule of git rebase is to never use it on public branches. The rebase moves all of the commits in main onto the tip of feature . The problem is that this only happened in your repository. All of the other developers are still working with the original main .
I don't know how you got yourself into this situation, but I can tell you how to get yourself out.
First, create a new branch based on the upstream SVN: git checkout -b mynewbranch refs/remotes/oldbranch (use the git-svn ref ID here).
Then, check it out: git checkout mynewbranch.
Finally, cherry-pick the commits from your new branch which were not committed to SVN (something like git cherry-pick refs/remotes/oldbranch..oldbranch.
The most likely cause of the problems you're seeing is that you rewrote history after pushing a change to SVN; when you use git-svn to make a commit, it puts the git-svn-id in the commit log, which changes the revision hash. If you then move the commit around, you start working in an alternate universe where the SVN versions conflict with the non-SVN local ones.
62
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
