1

I'm trying to apply a patch file (1) I found online to Blender (2). However, with so many versions in the official repository I'm not sure which version the patch should be applied to.

I checked out several earlier versions of Blender and tried

patch -p1 < ../blender-custom-nodes/patch/compositor_nodes.diff

but all of them results in some rejects. Is there any easy way to tell which version the patch should be applied to?

(1) https://github.com/bitsawer/blender-custom-nodes (2) https://developer.blender.org/diffusion/B/branches/master/

matohak
  • 535
  • 4
  • 19

2 Answers2

3

... Is there any easy way to tell which version the patch should be applied to?

Only if the patch contains an index line. (Even then, it's not necessarily easy, and there may be many revisions to which the patch might apply.) In this case, that patch does have such a line:

diff --git a/extern/CMakeLists.txt b/extern/CMakeLists.txt
index 91919ad..fed9e0c 100644
--- a/extern/CMakeLists.txt
+++ b/extern/CMakeLists.txt
@@ -37,6 +37,7 @@ if(CMAKE_COMPILER_IS_GNUCC)
[snip]

The index line in a Git diff provides the old and new blob hash IDs. This means the version of CMakeLists.txt to which the patch applies is a blob whose abbreviated hash ID is 91919ad. If this hash ID is not uniquely some particular blob, one is in trouble; cloning the repository as it is today, I find:

$ git rev-parse 91919ad
91919adb4a289234062a27bed0276cb098d1e5d5

so we can use the answers from Which commit has this blob?

Rather than the fancy perl script, I went with VonC's answer:

$ git log --oneline --find-object=91919adb4a289234062a27bed0276cb098d1e5d5
e0597baed57 Remove Carve boolean
e8daf2e3ea1 CMake: cleanup

Note that we could use the abbreviated hash here since it's still unique:

$ git log --oneline --find-object=91919ad
e0597baed57 Remove Carve boolean
e8daf2e3ea1 CMake: cleanup

It's best to keep the full hash ID around, though, as eventually, the shortened hash may become non-unique and only a longer hash will serve. (The full hash will always work, as there's nothing longer than the full hash.)

Note that there are many commits "between" these two:

$ git rev-list --count e8daf2e3ea1..e0597baed57
752

All of those commits (except the last one) share that one version of extern/CMakeLists.txt:

$ git show e8daf2e3ea1 -- extern/CMakeLists.txt
commit e8daf2e3ea17c2e9569e6fc9b49879c74d9a8c22
Author: Campbell Barton [snip]

diff --git a/extern/CMakeLists.txt b/extern/CMakeLists.txt
index f7e98525b8b..91919adb4a2 100644
--- a/extern/CMakeLists.txt
+++ b/extern/CMakeLists.txt
[snip]

This commit is the start of the 751 commits that contain that version of that file. Meanwhile:

$ git show e0597baed57 -- extern/CMakeLists.txt
commit e0597baed57fa7a9dfaf6dff6d0fa120784d21ea
Author: Sergey Sharybin [snip]

diff --git a/extern/CMakeLists.txt b/extern/CMakeLists.txt
index 91919adb4a2..2e8589ffd17 100644
--- a/extern/CMakeLists.txt
+++ b/extern/CMakeLists.txt

This is the first commit that stops using that version of extern/CMakeLists.txt (after which no other master-branch version uses it).

torek
  • 448,244
  • 59
  • 642
  • 775
  • "Rather than the fancy perl script, I went with VonC's answer:" Warning, my answer (https://stackoverflow.com/a/48590251/6309), with its `git log --oneline --find-object=v2.0.0:Makefile`, is for Git 2.17 or more. – VonC Nov 04 '18 at 03:58
  • Thanks! So given each file were changed versus a different commit, is there any way to checkout just one version along the branch so I can apply the patch to all files in a single line? – matohak Nov 04 '18 at 11:53
  • @matohak: no, but that does not make sense anyway. Consider this rather weak analogy: someone says that if you wear a red hat on Tuesday, or a blue shoe on Friday, you can get into some particular club. Wearing a red hat *and* a blue shoe together on Wednesday or Thursday is not a winning combination. If you have patch A for version A, patch B for version B, and patch C for version C, it doesn't follow that applying all three patches to any one version will produce something that works. This, of course, is the point of *commits* rather than patches: a commit is [continued] – torek Nov 04 '18 at 12:00
  • ... a commit is a single version, in which *every* file is consistent with *every other* file. If someone sends a patch, instead of a commit, they should tell you which commit the patch applies to, rather than making you guess. That patch will then apply to all the files from that particular commit. – torek Nov 04 '18 at 12:00
  • That's what I wanted to know. If they didn't tell me which commit the patch applies to, how can I find out? Does that mean I have to guess? – matohak Nov 04 '18 at 12:19
  • Apparently so. I did not look over the linked repository closely; perhaps there is some clue in there? – torek Nov 04 '18 at 12:22
0

I was able to apply the patch using blender v2.79 (8ef39d5c882896bd75e0d4d17fb3e3d4710fc768).

nonameentername
  • 434
  • 7
  • 8