Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Error with git rebase ("could not apply...")

I'm the administrator of the GitHub repository https://github.com/plison/opendial. I would like to reduce the number of commits on the repository, since the repository already has a few thousand commits, many of whom are minor debugging changes that could easily be squashed together (especially the ones that are a few years old).

I'm therefore trying to apply rebasing in order to squash together part of my commits. However, I've experience the following issue:

  1. When I type e.g. git rebase -i HEAD~10, I get a quite long number of commit lines (much more than 10) in the interactive editor. What could be the reason?
  2. More importantly, once I close the interactive editor to start the rebasing, I systematically get the error message "error:could not apply ', even when I do not make any change to the commits (i.e. if I leave all lines as 'pick', without any modification or reordering).

How can I solve these issues? It should be noted that the repository was automatically imported from a previous (SVN) repository hosted on Google Code. The conversion seemed so far to have worked well, but I'm wondering why I get these errors when trying to rebase my commits.

like image 874
Pierre Lison Avatar asked Jun 26 '15 09:06

Pierre Lison


People also ask

How do I resolve a rebase error in git?

You can run git rebase --abort to completely undo the rebase. Git will return you to your branch's state as it was before git rebase was called. You can run git rebase --skip to completely skip the commit.

What is rebase error?

If you type git rebase --continue. you realize the error is because of a merge conflict that git cannot resolve by itself, and needs your help. To see what files have conflicts, type git status. Resolve the merge conflicts in your favorite editor/IDE (hint: this should start with i and end with ntelliJ)

How do you resolve conflicts in rebasing?

If the change that you submitted has a merge conflict, you need to manually resolve it using git rebase. Rebasing is used to integrate changes from one branch into another to resolve conflicts when multiple commits happen on the same file. Never do a rebase on public (master) branches. You submit a change.


2 Answers

As a reminder to myself on how to resolve this:

The error message is not very informative. If you type

git rebase --continue

you realize the error is because of a merge conflict that git cannot resolve by itself, and needs your help.

To see what files have conflicts, type

git status

Resolve the merge conflicts in your favorite editor/IDE (hint: this should start with i and end with ntelliJ)

Mark resolution with

git add .

If all the conflicts are resolved, you should see something like this:

(all conflicts fixed: run "git rebase --continue")

So continue your rebase with

git rebase --continue

Hopefully your rebase should now be successful

git status

shows:

On branch feature/DIG-19302-Upgrade-mockito-v2
Your branch is behind 'origin/feature/your-feature-branch' by 2 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)

nothing to commit, working directory clean

Don't do a git pull. If you do, you will only overwrite your merge conflicts. Instead push your merge conflict resolutions to the branch) with

git push --force

You're done! Your git log should show only 1 commit now (which is the forced update you just did)

like image 131
Somaiah Kumbera Avatar answered Oct 04 '22 10:10

Somaiah Kumbera


The history of your project seems to contain a number of merge commits recently (presumably you made those). The presence of merge commits in what you want to interactively rebase usually causes problems. (An interactive rebase pretty much assumes a linear history, but merge commits are not linear.)

Your project history also somehow seems to have two parallel histories that are merged together in commit 11b3653 (use a tool like gitk or tig to see this, it's not shown well on Github's web interface).

I would suggest that you attempt to first flatten your history to get rid of the parallel histories, and to remove the merge commits. Then, once you have a strictly linear history, you can set about rewriting the history to remove all the debugging churn.

like image 32
Greg Hewgill Avatar answered Oct 04 '22 09:10

Greg Hewgill