4

So, I have a number of Wordpress sites managed with a Git repository, all of which are branches off of a central upstream Git repository. I recently applied a bunch of updates to the parent repo, but one of the child website repos had a plugin updated to a different version and now throws up about 400 rename/rename conflicts. All of these conflicts are in an upstream plugin directory that would be safe to just resolve in favor of the upstream branch.

I want to do the following:

  1. Ensure the upstream version of the files 'wins' the merge conflict (e.g. what the --theirs flag does with checkout)
  2. Produce a mergeable history (If it's not safe for a coworker to type "git pull origin master" with an old repo, it's not an option. I'm religiously opposed to rebasing.)
  3. Not restructure my Git repository (My hosting provider, Pantheon, will not install Composer dependencies at deploy time. Upstream plugins have to be part of the repo.)
  4. Not get a repetitive stress injury (Has to be a reasonably small number of commands because I have to resolve these kinds of messes once a month or so.)

If I just type "git checkout wp-content/plugins/** --theirs", I get hit in the face with about 400 errors, and Git refuses to checkout the files. They look like this:

....400 or so errors omitted...
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-quick-edit-handler-710.min.js' does not have their version
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-quick-edit-handler-720.min.js' does not have their version
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-recalculate-710.min.js' does not have their version
error: path 'wp-content/plugins/wordpress-seo/js/dist/wp-seo-recalculate-720.min.js' does not have their version

I categorically refuse to type 400 git rm/git add commands with each individual path included. git checkout --force is not an option, as --theirs and --force are mutually incompatible (for some reason). My current solution is to open Git GUI and manually right-click -> Use Remote Version and then click Yes... 400 times. I don't have to type the path at least but this is still time consuming.

How do I efficiently resolve a large number of rename/rename conflicts in favor of the remote repository?

Libertardian
  • 391
  • 3
  • 5

1 Answers1

1

Do you want to just resolve the conflicted files in favour of the remote, or just take a whole tree as it is in the remote?

For the latter, you could do this:

  • Just accept the files as-is with conflicts. git add . or similar
  • Commit the merge.
  • rm -Rf path/in/question
  • git checkout origin/branch -- path/in/question
  • git commit --amend -a

For the former, it's probably something pretty similar

  • Just accept the files as-is with conflicts. git add . or similar
  • Commit the merge.
  • Find files with conflicts. e.g. grep -r -l '>>>>' path/in/question > /tmp/conflicts.txt
  • Delete the files with conflicts, check out the desired versions, and amend the commit in a similar means to the above.

(If there are files/paths with spaces in them, small adjustments to the above commands may be necessary. I've given the simpler versions for clarity.)

Mort
  • 3,379
  • 1
  • 25
  • 40
  • These are rename/rename conflicts, so the latter solution wouldn't solve the issue. Grep wouldn't catch anything. The former solution I tried, but git checkout still refused to checkout the files, giving me the same error message. I didn't try committing the merge with conflicts, though - that may have been the solution. Unfortunately I don't have the broken repository anymore to check, since I fixed it the hard way. (Also, I'm sorry for hitting you thrice with deleted comments, but Slack insists on treating enter as submit on a – Libertardian May 03 '18 at 14:32
  • The great thing about git is that you can redo almost any operation. Should be easy to `git reset --hard` back to your original state, redo the merge, and try it out. – Mort May 03 '18 at 16:44