151

I just did a git pull --rebase origin master and there was a conflict.

Firstly, this conflict was in a file that I hadnt touched, and was about 10 commits back. Why does this happen?

I then accidently typed git rebase --skip, and it 'skipped that patch'.

Worried that I had skipped a commit, I checked out a new version of the master branch and did a diff between the branch that I did the rebase on, and the new master branch. The only changes that show up in the diff are the latest commit, and looking at the log, the patch that was 'skipped', shows up in the commit history.

Can anyone explain what is going on here?

mrwooster
  • 23,789
  • 12
  • 38
  • 48

3 Answers3

82

It does what it says, it skips a commit. If you run rebase --abort at a later conflict during the same rebase, the skipped commit will be reverted too of course.

If your change already existed upstream, Git will not be able to apply your commit (but usually should skip it automatically, if the patch is exactly the same). Your own commit will be skipped, but the change will still exist in current HEAD, because it was already applied upstream.

You should really make sure you did not remove an important change of yours ;) (use the reflog to go back to the state before the rebase)

knittl
  • 246,190
  • 53
  • 318
  • 364
  • 5
    So why is the commit still showing up in the log? And why does the missing commit now show up in the diff? – mrwooster Mar 02 '12 at 19:39
  • What was the conflict? Maybe your patch was already applied upstream. Git would complain about an empty commit then, though. – knittl Mar 02 '12 at 19:42
  • 4
    Yes, the conflict had already been resolved upstream... for some reason git rebase brings up old merge conflicts... another thing that confuses me?... does this mean that it skipped the conflict, but applied the patch that resolved the conflict? – mrwooster Mar 02 '12 at 19:59
  • 4
    You skipped your own commit, which had the same change as a commit upstream. You skipped your commit, but the change was still made (because it already existed upstream) – knittl Mar 02 '12 at 20:19
  • Ah, ok, I think that kinda makes sense. Can you edit your answer and I will accept. Ty – mrwooster Mar 02 '12 at 20:41
  • It looks like it skips the entire commit even if some of it could be applied. Is there any way to skip just the conflicting files? – Brian White Mar 14 '14 at 12:41
  • @BrianWhite: I guess not. You can manually fix the conflicting files (e.g. checking out `ours` or `theirs`) and then do `git rebase --continue` – knittl Mar 14 '14 at 13:53
  • I realise that this is an old thread, but didn't want to duplicate it by starting afresh. I am stuck in a situation I described here [query](https://stackoverflow.com/questions/47587688/how-to-git-rebase-while-overriding-specific-conflicts-with-upstream-code) Is `--skip` the way to achieve this ? – mittal Dec 15 '17 at 04:20
  • 2
    @mittal no, I don't think `--skip` is the way to go. Skip will skip a commit entirely, dropping all changes made in this commit. – knittl Dec 17 '17 at 08:45
  • 2
    @knittl When we say 'this commit' I can't understand what is 'this' ? Is it the local change or the one coming from upstream ? There is .gitreview change coming from upstream and if I do `--skip` it accepts the upstream one which is what I want – mittal Dec 17 '17 at 11:52
  • 5
    @mittal: think of `git rebase` as _copying_ commits from one branch onto another branch. So when you skip a commit, the _original_ content of the commit is skipped and the patch is not applied (so all changes made to any file will not make it into your target branch). Easiest way is to set up a simple git repository with two branches, several commits on each of them and then try to rebase and skip a commit (you can use `git rebase --interactive` to specify which commits will be copied (`pick`) or skipped (`skip`) – knittl Dec 17 '17 at 12:06
  • To see how "(use the reflog to go back to the state before the rebase)" would look like: [Undoing a git rebase](https://stackoverflow.com/questions/134882/undoing-a-git-rebase). – questionto42 Apr 19 '22 at 14:35
  • Correction: [My previous comment](https://stackoverflow.com/questions/9539067/what-exactly-does-git-rebase-skip-do/9539315#comment82673847_9539315) stated incorrectly that the action of interactive rebase is called `skip`. The actions are called `pick` to copy and `drop` to skip a commit. – knittl Aug 16 '22 at 21:47
6

I frequently bump into this myself when I know there shouldn't be any conflict and the listed conflicts don't make any sense. As an example, I had several branches in order like this:

A --> B --> C --> D --> E ...

One of the modifications in branch D was to add a file and I realized that it made more sense to add that file at branch B. So I did

  git switch B
  git checkout B -- path/to/new/file
  git commit --amend --no-edit

Then I did

  git switch C
  git rebase B

This worked fine but when I did

  git switch D
  git rebase C

There were conflicts. I was able to fix it manually, but I also found that I could

  git rebase --skip

and everything was fine. Then when I did

  git switch E
  git rebase D

the same conflicts occurred. Again, I could either fix it manually or skip it with the same result.

I am still trying to get my head around why these conflicts sometimes occur and why it sometimes works to do a

  git rebase --skip

in situations like this.

beevis
  • 73
  • 1
  • 7
0

It skips that commit. In an interactive rebase, if you drop commits, and skip the merge conflict, that commit will be removed.

^ eee pick
| ddd pick
| ccc drop
| bbb drop
| aaa pick

If there is a merge conflict, it will be for commit: ddd. If you ran: git rebase --skip git would say: could not apply ddd. and your branch would look like this:

^ eee
| aaa

Note: eee would actually be re-written as a different commit id.

PhillipMcCubbin
  • 495
  • 1
  • 4
  • 10