Search code examples
gitrebase

resolve all "changed-by them" or "deleted by the them" during rebase

I'm doing a rebase where I would like to always take the conflicting files as-is from the branch A.

on branch A

git rebase -X theirs branchQ

( According to Is there a "theirs" version of "git merge -s ours"? and Choose Git merge strategy for specific files ("ours", "mine", "theirs") : "theirs" should mean "use the versions from A". In rebase the meaning of theirs and ours are reversed with respect to a merge )

But, I still get conflicts for files that were modified and deleted. I would like to go with the contents for A all the time.

git status

Unmerged paths:
  (use "git reset HEAD <file>..." to unstage)
  (use "git add/rm <file>..." as appropriate to mark resolution)

        deleted by them: A/XB.cs
        deleted by them: A/YB.cs
        deleted by them: B/XD.cs
        deleted by them: B/YD.cs

and MANY more.

I can fix this by git rm A/XB.cs etc, but how can I accept all these deletions (and all other changes from branch A)? (It's a 28 stage rebase, so I'm looking for automation)

With respect to the common parent of branches A and branchQ, branchQ contains only line-ending normalizations, not new or deleted files.

Solution

  • The short answer is that -X arguments have no effect at all on what I call high level conflicts. See "-X theirs" option does not seem to work with certain Git conflicts and also What are the reasons and cases that cause git merge conflicts?

    I do not have a canned script that will do this for you, but experiment with:

    git ls-files --stage

    Note that files that were "deleted by them" will exist as entries in staging slots 1 and 2 but not in slot 3. These are the names to pass to git rm to tell Git to remove the stage 1 and 2 entries.

    For a description of how merge uses the four staging slots allowed for each file entry in the index, see How do contents of git index evolve during a merge (and what's in the index after a failed merge)?