gitgit-rebasegit-merge-conflict

Git Rebase repeats conflicts from last Rebase


Are there any common git usage mistakes or in general any reasons at all why a rebase would repeat the conflicts from the previous rebase if those conflicts had all been resolved in the previous rebase?
Furthermore, does rebase have a preference over how the conflict was resolved? e.g. does rebase want a strict choice between the two possible code snippets in the usual git conflict brackets within the code or is it just as fare to it to remove everything between the >>>,<<<? I'm curious if removing both code choices to resolve the conflict will affect rebase's ability to resolve later conflicts properly.

Further elaboration: I have a master branch and a dev branch. The dev branch I've been working on the side for some time so the number of differing commits has grown quite large, in the 100s (I know...should dev into master more often). dev branch itself has had several smaller feature branches cut from it and then merged back in, only ever having been cut, rebased, merged with dev branch and never master branch (that I can remember). I rebased dev branch onto master branch 1 week ago. I have since made a few more changes on dev branch and would like to rebase on master once again so I can prepare for a merge. There has been a very small change to master branch in that 1 week window as well but the code files don't overlap. However, when rebasing dev onto master I'm seeing the same set of conflicts being raised by git when I attempt the current rebase as compared to when I rebased one week ago.

Thanks!


Solution

  • In general, it's normal - if you rebase like this rather than merging (eg. master into dev), then replaying the same patches will likely generate the same conflicts.

    You can use git rerere to remember your resolutions if this is a common problem in your workflow.

    Firstly, you should enable git rerere in config, like

    $ git config rerere.enabled true
    

    Now conflicted merges and rebases will automatically use git rerere to save the state at the start of manual resolution (you'll see a message like Recorded preimage for ...).

    When you've finished manual resolution, run git rerere again (before git rebase --continue or whatever), and it will record your decisions (you'll see Recorded resolution for...).

    The next time a conflict occurs, git rerere will be invoked as before, and it will check whether any of the recorded manual resolutions can be applied again.

    In addition, you should be using a good 3-way diff tool to help. You can use git mergetool for resolving rebase just the same as merge conflicts.