56

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.

Pierre Lison
  • 678
  • 1
  • 5
  • 7
  • 3
    Don't do this, it's a terrible idea. For reasons see: http://superuser.com/a/667200/83759, and the Pro Git book says: "In general the way to get the best of both worlds is to rebase local changes you’ve made but haven’t shared yet before you push them in order to clean up your story, but never rebase anything you’ve pushed somewhere." (https://git-scm.com/book/en/v2/Git-Branching-Rebasing) – Stuart Grassie Jun 26 '15 at 09:25

2 Answers2

80

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)

Mark Lakata
  • 19,989
  • 5
  • 106
  • 123
Somaiah Kumbera
  • 7,063
  • 4
  • 43
  • 44
  • The last point is key. I tried to do a git push, getting an out of date error, doing git pull and then a file to be merged again. git push --force solved the issue for me. – Jose Gómez Feb 10 '17 at 01:53
  • 11
    I'm a bit curious; in what language does vim begin with i and end with ntelliJ? – Shuklaswag Aug 17 '17 at 19:23
  • @Shuklaswag good point. I used to integrate intelliJ as my git editor, but use just vim now. – Somaiah Kumbera Aug 21 '17 at 08:11
  • 1
    `git add .` is a bad idea. git rebase/merge generally create `.orig` files for the conflicting files and this will add even those files into the staging area. You should only do `git add` on those files that you actually want to commit. – Pavan Manjunath Nov 20 '18 at 00:47
  • weirdly just `git rebase --continue` alone worked for me. – Declan McKenna Nov 04 '19 at 15:13
22

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.

Greg Hewgill
  • 951,095
  • 183
  • 1,149
  • 1,285
  • 9
    Interesting that most answers to flatten git history are recommending git rebase but using git rebase to to resolve error with git rebase makes things complicated :) I would like to group commits into few groups and only options seems git squash merge with given author of original commit. – kodstark Mar 02 '16 at 12:09