171

I am on windows.

For various reasons we have multiple git instances of different svn branches.

Many times I want to fix an issue in repository A, generate a patch, and apply it to repository B. This works fine except if there are conflicts.

When rebasing I just right click the folder and use tortioseGit and select the resolve option. This brings up a nice gui to let me work through my conflicts.

Is there any way to accomplish this with rejected patch chunks?

Here is my current approach to creating/applying the patches

git format-patch master --stdout > c:\\patch\\file.patch
git apply --reject --ignore-space-change --ignore-whitespace c:\\patch\\file.patch
max630
  • 8,762
  • 3
  • 30
  • 55
Kenoyer130
  • 6,874
  • 9
  • 51
  • 73
  • 3
    I usually do it by hand when all patching options fail... – stdcall Jun 06 '13 at 13:58
  • If the merge fails, it is because the program _can't_ figure out how to un-ambiguously do the merge. You should get a file with <<<<, ===, >>>> sets and you have to go in and resolve them by hand. – tacaswell Jun 06 '13 at 14:50
  • Yeah doing it by hand is a real pita when your talking a few 100 rej hunks. – Kenoyer130 Jun 06 '13 at 19:23
  • 1
    That's when you'd want to use `git mergetool` and do a 3-way merge with the gui of your choice (i'm partial to kdiff on windows)... – g19fanatic Jun 09 '13 at 22:27

5 Answers5

348

To generate your patch do the following:

git format-patch --stdout first_commit^..last_commit > changes.patch

Now when you are ready to apply the patches:

git am -3 < changes.patch

the -3 will do a three-way merge if there are conflicts. At this point you can do a git mergetool if you want to go to a gui or just manually merge the files using vim (the standard <<<<<<, ||||||, >>>>>> conflict resolution).

phuclv
  • 37,963
  • 15
  • 156
  • 475
g19fanatic
  • 10,567
  • 6
  • 33
  • 63
  • I didn't know about the `...` notation; it's documented in the [gitrevisions(7)](https://www.kernel.org/pub/software/scm/git/docs/gitrevisions.html) man page. – Keith Thompson Jun 06 '13 at 18:11
  • There certainly are alot of ways to get the commits you want and nothing else... That being said, what I was trying to convey is not what I actually said... Now it is fixed to really mean what I wanted... (or so I think...)... – g19fanatic Jun 06 '13 at 18:36
  • 9
    It may be useful to add `--ignore-whitespace --ignore-space-change` to `git am` too. I had trivial merges that did not go through without it. – angularsen Aug 27 '15 at 06:33
  • 23
    `git apply -3 changes.patch` seems to work for me as well – peterflynn Oct 14 '15 at 21:44
  • git -am -3 works for me. After git am -3 , I have to stage all the changes with git add patch. git am --continue. Then the patch will be applied successfully. – 4t8dds Mar 13 '17 at 03:00
  • 3
    Even though the patch doesn't apply cleanly I still get "No files need merging" from `git mergetool`. Instead I had to find the base commit the original patch used, apply on top of that (luckily my repo had this) and then rebase. – jozxyqk Sep 11 '18 at 19:01
  • 7
    I'm having the same problem as @jozxyqk. Neither `git am -3` nor `git apply -3` will actually drop conflict markers into my files, even though I get messages like `Applied patch to 'configure.ac' with conflicts.` and `error: patch failed: ...`. This is on `git 2.17.1`. Perhaps when some files can't be patched at all, git rolls back? – nh2 Nov 13 '18 at 23:35
  • 2
    I got the same issue as @nh2, did you ever find the problem? – Eridanis Mar 01 '19 at 12:06
  • 1
    I wonder if this really works according the original question, when those commits (index SHAs in patch) are alien to the current repo? (No good test at hand, but `-3` won't work with patches processed e.g. with `interdiff` or other advanced means. It requires to first establish the starting file state (e.g. committing a copy) of at least the conflicting files somewhere in the current repo at a suitable parent (with good similarity), and from there do `apply + rebase / cherry-pick`) – kxr Mar 29 '22 at 20:54
16

If you are frequently running into the same conflict set when applying patches, rebasing or merging then you can use git rerere (reuse recorded resolution) function. This allows you to pre-define how conflicts should be resolved based on how you resolved them in the past. See http://git-scm.com/blog/2010/03/08/rerere.html for details of how this works.

mproffitt
  • 2,409
  • 18
  • 24
8

Just use

git apply -3 <patch_name>

it will allow you to fix conflicts

kvaps
  • 2,589
  • 1
  • 21
  • 20
5

TortoiseGit has a merge feature that can open patch files.

There's a picture of it here.

MrTux
  • 32,350
  • 30
  • 109
  • 146
ams
  • 24,923
  • 4
  • 54
  • 75
  • 1
    Actually the merge option might be what I'm looking for. – Kenoyer130 Jun 06 '13 at 19:28
  • Really? I've not used tortoise in a long time, but the linked page has the text "TortoiseMerge can open Git patch file directly, you review it and patch to working copy.", so it seems like it should! – ams Jun 07 '13 at 19:48
  • it does open patch files... however, sometimes the patch file format breaks tortoisegitmerge. i've never been successful with diff -u, but rather diff -c output. – thistleknot Aug 19 '14 at 17:46
  • You can also right drag patches on a working tree folder and select "Apply patch serial" (for patches like 0001-xxx.patch, ... 0002-xxy.patch) or "Apply single patch file". – MrTux Sep 06 '15 at 19:24
4

My approach is:

  • Create an "Integration"-Branch where the files are identical
  • Apply the patch to this Integration-Branch
  • Merge or rebase it to master (don't know if rebase is useful here, because I don't know what will happen when applying further patches)
MichiBack
  • 1,310
  • 13
  • 12