{"thread":{"id":"64454","subject":"[Bug report] git cherry-pick silently ignores error whereas git apply fails for hunk apply","startedAt":"2025-11-07T04:39:44Z","lastAt":"2025-11-09T10:10:01Z","messageCount":7,"participants":["Bhavik Bavishi","Johannes Sixt","Chris Torek"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"530353","messageId":"CAEyHQXWd77_jJachC6FYbWMJ+L=KkKoUqiACQ7z8r-ZwYq8JYw@mail.gmail.com","threadId":"64454","inReplyTo":null,"subject":"[Bug report] git cherry-pick silently ignores error whereas git apply fails for hunk apply","fromName":"Bhavik Bavishi","fromEmail":"bhavikdbavishi@gmail.com","sentAt":"2025-11-07T04:39:32Z","receivedAt":"2025-11-07T04:39:44Z","isPatch":false,"sender":{"key":"bhavikdbavishi@gmail.com","avatar":"https://gravatar.com/avatar/aaefd93ba9f5c7aa32b90ece242f4eb00076a893ef70d9cf9939000ad1c5352a?d=mp&s=160"},"body":"Thank you for filling out a Git bug report!\nPlease answer the following questions to help us understand your issue.\n\nWhat did you do before the bug happened? (Steps to reproduce your issue)\n> ran git cherry-pick command, which went fine without any error, but missed to apply change\n> created patch with 'git fromat-patch' and applied with 'git apply --verbose', which error for the issue\n\nWhat did you expect to happen? (Expected behavior)\n> git cherry-pick should fail, since it failed to apply hunk\n\nWhat happened instead? (Actual behavior)\n> git cherry-pick completed successfully without any error\n\nWhat's different between what you expected and what actually happened?\n> git apply --verbose, failed with error about the issue, whereas git cherry-pick didn't fail for the same\n\nAnything else you want to add:\n> same error observed with '2.51.2' version as well\n> we do primarily use Gerrit UI for cherry-pick, so JGIT has similar behaviour as git cli for cherry-pick.\n\n> can we have verbose mode for git cherry-pick, like git apply --verbose ?\n\n> below is output of git apply (note I've changed words for source code references)\n=======================================================================\ngit apply --verbose ../test.patch\nChecking patch mango/connectors/apple/ops/query_check_hierarchy_op.cc...\nChecking patch mango/connectors/container/loc_base/util.cc...\nChecking patch mango/connectors/container/loc_base/util.h...\nChecking patch mango/main/http_test_ops/new_op.cc...\nHunk #1 succeeded at 56 (offset 2 lines).\nHunk #2 succeeded at 1074 (offset 21 lines).\nChecking patch mango/main/main.cc...\nHunk #1 succeeded at 9876 (offset -63 lines).\nChecking patch mango/main/ops/refresh_apple_hierarchy_op.cc...\nHunk #4 succeeded at 1713 (offset 18 lines).\nChecking patch mango/main/validation_util.cc...\nHunk #1 succeeded at 42 (offset -1 lines).\nHunk #2 succeeded at 106 (offset -2 lines).\nHunk #3 succeeded at 11167 (offset -14 lines).\nChecking patch mango/conn/ops/apple_box_storage_package_op.cc...\nChecking patch mango/utils/apple_utils.cc...\nerror: while searching for:\n\n//-----------------------------------------------------------------------------\n\n// Returns true if Apple Box Pack usecases + the corresponding updates flag\n// is enabled.\nbool Converter::IsAppleBoxPackEnabled(\n std::shared_ptr updates_checks,\n std::shared_ptr\n newed_params) {\n for (const auto& usecase :\n newed_params->apple_params().use_cases()) {\n if ((usecase == RegisteredAppleParams_UseCase_kBoxPack) &&\n updates_checks->updates_list_map()\n .apple_box_storage_protection_enabled()) {\n return true;\n }\n }\n return false;\n}\n\n//-----------------------------------------------------------------------------\n\n}}} // namespace org::mango::apple\n\nerror: patch failed: mango/utils/apple_utils.cc:658\nerror: mango/utils/apple_utils.cc: patch does not apply\nChecking patch mango/utils/apple_utils.h...\n=======================================================================\n\nPlease review the rest of the bug report below.\nYou can delete any lines you don't wish to share.\n\n\n[System Info]\ngit version:\ngit version 2.34.1\ncpu: x86_64\nno commit associated with this build\nsizeof-long: 8\nsizeof-size_t: 8\nshell-path: /bin/sh\nuname: Linux 5.15.0-160-generic #170-Ubuntu SMP Wed Oct 1 10:06:56 UTC\n2025 x86_64\ncompiler info: gnuc: 11.4\nlibc info: glibc: 2.35\n$SHELL (typically, interactive shell): /bin/bash\n\n\n[Enabled Hooks]\ncommit-msg\n"},{"id":"530357","messageId":"e1fede83-bed0-49e9-84a0-f026b9df6039@kdbg.org","threadId":"64454","inReplyTo":"CAEyHQXWd77_jJachC6FYbWMJ+L=KkKoUqiACQ7z8r-ZwYq8JYw@mail.gmail.com","subject":"Re: [Bug report] git cherry-pick silently ignores error whereas git apply fails for hunk apply","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2025-11-07T06:37:46Z","receivedAt":"2025-11-07T06:37:50Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 07.11.25 um 05:39 schrieb Bhavik Bavishi:\n> What did you do before the bug happened? (Steps to reproduce your issue)\n>> ran git cherry-pick command, which went fine without any error, but missed to apply change\n>> created patch with 'git fromat-patch' and applied with 'git apply --verbose', which error for the issue\n> \n> What did you expect to happen? (Expected behavior)\n>> git cherry-pick should fail, since it failed to apply hunk\n> \n> What happened instead? (Actual behavior)\n>> git cherry-pick completed successfully without any error\n> \n> What's different between what you expected and what actually happened?\n>> git apply --verbose, failed with error about the issue, whereas git cherry-pick didn't fail for the same\n\n\nIf you use `git apply --3way`, does it still fail, or does it succeed\nand does it produce the same result as `git cherry-pick` or a different\nresult?\n\n-- Hannes\n\n"},{"id":"530360","messageId":"CAEyHQXWd4kN=ehWh0Y7xNnPGk3ofXEc4=PvSYaZM91TFyLtnpg@mail.gmail.com","threadId":"64454","inReplyTo":"e1fede83-bed0-49e9-84a0-f026b9df6039@kdbg.org","subject":"Re: [Bug report] git cherry-pick silently ignores error whereas git apply fails for hunk apply","fromName":"Bhavik Bavishi","fromEmail":"bhavikdbavishi@gmail.com","sentAt":"2025-11-07T08:35:33Z","receivedAt":"2025-11-07T08:35:45Z","isPatch":false,"sender":{"key":"bhavikdbavishi@gmail.com","avatar":"https://gravatar.com/avatar/aaefd93ba9f5c7aa32b90ece242f4eb00076a893ef70d9cf9939000ad1c5352a?d=mp&s=160"},"body":"git apply --3way --verbose ../test.patch ; echo $?\nChecking patch mango/connectors/apple/ops/query_check_hierarchy_op.cc...\nApplied patch to\n'mango/connectors/apple/ops/query_check_hierarchy_op.cc' cleanly.\nChecking patch mango/connectors/container/loc_base/util.cc...\nApplied patch to 'mango/connectors/container/loc_base/util.cc' cleanly.\nChecking patch mango/connectors/container/loc_base/util.h...\nApplied patch to 'mango/connectors/container/loc_base/util.h' cleanly.\nChecking patch mango/main/http_test_ops/new_entity_op.cc...\nApplied patch to 'mango/main/http_test_ops/new_entity_op.cc' cleanly.\nChecking patch mango/main/main.cc...\nApplied patch to 'mango/main/main.cc' cleanly.\nChecking patch mango/main/ops/refresh_apple_entity_hierarchy_op.cc...\nApplied patch to 'mango/main/ops/refresh_apple_entity_hierarchy_op.cc' cleanly.\nChecking patch mango/main/validation_util.cc...\nApplied patch to 'mango/main/validation_util.cc' cleanly.\nChecking patch mango/conn/ops/apple_box_storage_package_op.cc...\nApplied patch to 'mango/conn/ops/apple_box_storage_package_op.cc' cleanly.\nChecking patch mango/utils/apple_utils.cc...\nApplied patch to 'mango/utils/apple_utils.cc' cleanly.\nChecking patch mango/utils/apple_utils.h...\nApplied patch to 'mango/utils/apple_utils.h' cleanly.\nApplied patch mango/connectors/apple/ops/query_check_hierarchy_op.cc cleanly.\nApplied patch mango/connectors/container/loc_base/util.cc cleanly.\nApplied patch mango/connectors/container/loc_base/util.h cleanly.\nApplied patch mango/main/http_test_ops/new_entity_op.cc cleanly.\nApplied patch mango/main/main.cc cleanly.\nApplied patch mango/main/ops/refresh_apple_entity_hierarchy_op.cc cleanly.\nApplied patch mango/main/validation_util.cc cleanly.\nApplied patch mango/conn/ops/apple_box_storage_package_op.cc cleanly.\nApplied patch mango/utils/apple_utils.cc cleanly.\nApplied patch mango/utils/apple_utils.h cleanly.\n0\n\nI've compare the file content of `mango/utils/apple_utils.cc` for `git\napply --3way` and `git cherry-pick` is same\n\nOn Fri, Nov 7, 2025 at 12:07 PM Johannes Sixt wrote:\n>\n> Am 07.11.25 um 05:39 schrieb Bhavik Bavishi:\n> > What did you do before the bug happened? (Steps to reproduce your issue)\n> >> ran git cherry-pick command, which went fine without any error, but missed to apply change\n> >> created patch with 'git fromat-patch' and applied with 'git apply --verbose', which error for the issue\n> >\n> > What did you expect to happen? (Expected behavior)\n> >> git cherry-pick should fail, since it failed to apply hunk\n> >\n> > What happened instead? (Actual behavior)\n> >> git cherry-pick completed successfully without any error\n> >\n> > What's different between what you expected and what actually happened?\n> >> git apply --verbose, failed with error about the issue, whereas git cherry-pick didn't fail for the same\n>\n>\n> If you use `git apply --3way`, does it still fail, or does it succeed\n> and does it produce the same result as `git cherry-pick` or a different\n> result?\n>\n> -- Hannes\n>\n"},{"id":"530396","messageId":"CAEyHQXUgzRnT=8Fydn9Ew6V29hfJcjR8i26mdvGOXaWD=agzNA@mail.gmail.com","threadId":"64454","inReplyTo":"CAEyHQXWd4kN=ehWh0Y7xNnPGk3ofXEc4=PvSYaZM91TFyLtnpg@mail.gmail.com","subject":"Re: [Bug report] git cherry-pick silently ignores error whereas git apply fails for hunk apply","fromName":"Bhavik Bavishi","fromEmail":"bhavikdbavishi@gmail.com","sentAt":"2025-11-08T03:44:04Z","receivedAt":"2025-11-08T03:44:16Z","isPatch":false,"sender":{"key":"bhavikdbavishi@gmail.com","avatar":"https://gravatar.com/avatar/aaefd93ba9f5c7aa32b90ece242f4eb00076a893ef70d9cf9939000ad1c5352a?d=mp&s=160"},"body":"> > If you use `git apply --3way`, does it still fail, or does it succeed\n> > and does it produce the same result as `git cherry-pick` or a different\n> > result?\n> I've compare the file content of `mango/utils/apple_utils.cc` for `git\napply --3way` and `git cherry-pick` is same\n\nIf I understand correctly, `git cherry-pick` is processed as expected, but for\nsome reason we are not able to follow this behavior because the end result is\nmissing content. expectation was to have this content either be applied\nsuccessfully or fail with a conflict (indicating it could not be applied).\n\nquery: is there a way to understand this behavior? Based on that, we can then\ncorrect or update the file format to avoid such issues in the future, or\nintroduce an additional process to run `git apply` (without `--3way`) and check\nif there is any hunk failed to apply and notify for the same.\n"},{"id":"530397","messageId":"6f9a0358-4d87-477a-a067-081ce6b2d102@kdbg.org","threadId":"64454","inReplyTo":"CAEyHQXUgzRnT=8Fydn9Ew6V29hfJcjR8i26mdvGOXaWD=agzNA@mail.gmail.com","subject":"Re: [Bug report] git cherry-pick silently ignores error whereas git apply fails for hunk apply","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2025-11-08T08:26:15Z","receivedAt":"2025-11-08T08:26:25Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 08.11.25 um 04:44 schrieb Bhavik Bavishi:\n>>> If you use `git apply --3way`, does it still fail, or does it succeed\n>>> and does it produce the same result as `git cherry-pick` or a different\n>>> result?\n>> I've compare the file content of `mango/utils/apple_utils.cc` for `git\n> apply --3way` and `git cherry-pick` is same\n> \n> If I understand correctly, `git cherry-pick` is processed as expected, but for\n> some reason we are not able to follow this behavior because the end result is\n> missing content. expectation was to have this content either be applied\n> successfully or fail with a conflict (indicating it could not be applied).\n> \n> query: is there a way to understand this behavior? Based on that, we can then\n> correct or update the file format to avoid such issues in the future, or\n> introduce an additional process to run `git apply` (without `--3way`) and check\n> if there is any hunk failed to apply and notify for the same.\n\n`git cherry-pick` and `git apply --3wax` use a merge strategy. If this\noperation omits a change, then it is usually the case that it was\ndetermined that the change was already applied independently. This in\nturn can happen in a situation where there are repeated occurrences of\nthe same text, and only some of them are changed, like this (and I am\nspeculating here):\n\nbase: ...ABC...ABC...\ntheirs: ...ABC...AXC...\nours: .........AXC...ABC...\n\nHere, the merge strategy thinks that the change of the second \"ABC\" to\n\"AXC\" on their side matches up with the first \"ABC\", but that has\nalready been changed to \"AXC\" independently on our side, hence, there is\nnothing more to do.\n\n-- Hannes\n\n"},{"id":"530398","messageId":"CAPx1GvcwAj5k0QEwxS8h=VNBNTgtxAaXGAf1a38Sb18COuSHEA@mail.gmail.com","threadId":"64454","inReplyTo":"CAEyHQXWd4kN=ehWh0Y7xNnPGk3ofXEc4=PvSYaZM91TFyLtnpg@mail.gmail.com","subject":"Re: [Bug report] git cherry-pick silently ignores error whereas git apply fails for hunk apply","fromName":"Chris Torek","fromEmail":"chris.torek@gmail.com","sentAt":"2025-11-08T10:57:47Z","receivedAt":"2025-11-08T10:58:01Z","isPatch":false,"sender":{"key":"chris.torek@gmail.com","avatar":"https://avatars.githubusercontent.com/u/16826774?v=4"},"body":"On Fri, Nov 7, 2025 at 12:35 AM Bhavik Bavishi wrote:\n\n[\"git apply\" fails, \"git apply --3way\" and \"git cherry-pick\" succeed, and:]\n\n> I've compare the file content of `mango/utils/apple_utils.cc` for `git\n> apply --3way` and `git cherry-pick` is same\n\nThis is all entirely normal. You're seeing the difference between a\n\"patch\" and an actual \"three way merge\". The cherry-pick command does a\nthree-way merge using the complete information available to it. The\napply command applies a simple patch, or, with \"--3way\", searches the\npatch for auxiliary information that may or may not provide the extra\ndetail needed for doing a three-way merge.\n\nTo understand this, we need to illustrate the difference between\nthese two ideas. Let's start with patches.\n\nA \"patch\" says \"we expect the file looks something like this, and\nwe would like to make certain changes in these areas\". If the file\n*does* look \"like this\" in the indicated areas, it's easy to apply\nthe patch:\n\n --- lines 15 through 19 of file.txt used to be like this\n +++ lines 15 through 20 of file.txt should now look like this\n we expect the file to\n look like this\n + and we should add a line\n and then the text\n goes on as before\n\nIf file `file.txt` has the desired lines at lines 15--19, and we\nadd the indicated text in the middle, we've \"patched\" the file to\nmatch the new desired result.\n\nBut what if the file, at lines 15 through 19, reads:\n\n we expect the file to\n look like this\n and we should add a line\n and then the text\n\nWell, it sure looks like that patch was already applied. We\ncan *guess* that it was in fact already applied, or we can search\nfor lines before or after lines 15 through 19 that read the\nexpected way.\n\nPatches can add, remove, or (depending on the kind of patch)\nchange lines (or characters within lines, or whatever: the\nmore general form is \"symbol by symbol, add/subtract/replace\").\n\nA *merge*, by contrast, takes two separate sets of patches:\n\n * First, there's a \"common base version\": a version both you\n and they, whoever they were, had that's absolutely 100%]\n identical in all respects.\n\n * Second, there's an \"ours\" version. By comparing the \"base\"\n version to the \"ours\" version, we find out what *we* changed.\n\n * Last, there's a \"theirs\" version. By comparing the \"base\"\n version to the \"theirs\" version, we find out what *they* changed.\n\nThis time, if we already have the change at lines 15--19 / 15--20, we'll\nsee that they and we have the *same* change. We can silenly discard\ntheir duplicate change! We don't have to guess whether we have their\nchange, or whether the lines moved around somewhat in the file.\n\nThis same method handles removals (and if they're in the difference\nformat, \"changes\", which are just \"remove and add\" combined into one\nblock).\n\nThe way \"git apply --3way\" works is that it looks for a text line in the\npatch of the form \"index ..\" before the diff listing\n(which has only add and remove, in Git's case). The first hash ID in\nthis pair of hash IDs is the Git-specific unique identifier for the\noriginal version of the file. Git then looks in your own Git repository\nto see if you have that version of the file. If so, that's the\n\"common base version\".\n\nIf Git can find the base version this way, Git can then apply the patch\ndiff to the *base* version, which produces the \"theirs\" version,\nguaranteed, because the change *must* apply to the base. That ID is\n*unique*, across the entire universe of every file in existence\nanywhere, in any Git repository.[footnote] If you have that ID, you have\n*that version* of *that file*.\n\nNow that Git has the base version and the \"theirs\" version, Git can do\nits own three-way merge: diff the base vs your version to see what you\nchanged, and diff the base vs their version to see what they changed.\nThis can still have conflicts, but now at least they will always be in\nthe right places.\n\nChris\n\n[footnote] This is clearly nonsense, due to the pigeonhole principle.\nAnd yet, Git depends on it successfully (modulo carefully engineered\nhash collisions, currently possible for SHA-1 but not for SHA-256). With\nsome clever mathematics we can show that the chance of failure of any\ngiven Git repository is quite small -- far smaller than the chance that\nyour computer will just randomly explode into flames while you're using\nit, for instance.\n"},{"id":"530421","messageId":"CAEyHQXXKdVNRKzrTPJ1uVYVkpdMfCbSeXFW2TQJx6GNa4xStPw@mail.gmail.com","threadId":"64454","inReplyTo":"CAPx1GvcwAj5k0QEwxS8h=VNBNTgtxAaXGAf1a38Sb18COuSHEA@mail.gmail.com","subject":"Re: [Bug report] git cherry-pick silently ignores error whereas git apply fails for hunk apply","fromName":"Bhavik Bavishi","fromEmail":"bhavikdbavishi@gmail.com","sentAt":"2025-11-09T10:09:49Z","receivedAt":"2025-11-09T10:10:01Z","isPatch":false,"sender":{"key":"bhavikdbavishi@gmail.com","avatar":"https://gravatar.com/avatar/aaefd93ba9f5c7aa32b90ece242f4eb00076a893ef70d9cf9939000ad1c5352a?d=mp&s=160"},"body":"Thanks for the explanation this helps.\n\nOn Sat, Nov 8, 2025 at 4:28 PM Chris Torek wrote:\n>\n> On Fri, Nov 7, 2025 at 12:35 AM Bhavik Bavishi wrote:\n>\n> [\"git apply\" fails, \"git apply --3way\" and \"git cherry-pick\" succeed, and:]\n>\n> > I've compare the file content of `mango/utils/apple_utils.cc` for `git\n> > apply --3way` and `git cherry-pick` is same\n>\n> This is all entirely normal. You're seeing the difference between a\n> \"patch\" and an actual \"three way merge\". The cherry-pick command does a\n> three-way merge using the complete information available to it. The\n> apply command applies a simple patch, or, with \"--3way\", searches the\n> patch for auxiliary information that may or may not provide the extra\n> detail needed for doing a three-way merge.\n>\n> To understand this, we need to illustrate the difference between\n> these two ideas. Let's start with patches.\n>\n> A \"patch\" says \"we expect the file looks something like this, and\n> we would like to make certain changes in these areas\". If the file\n> *does* look \"like this\" in the indicated areas, it's easy to apply\n> the patch:\n>\n> --- lines 15 through 19 of file.txt used to be like this\n> +++ lines 15 through 20 of file.txt should now look like this\n> we expect the file to\n> look like this\n> + and we should add a line\n> and then the text\n> goes on as before\n>\n> If file `file.txt` has the desired lines at lines 15--19, and we\n> add the indicated text in the middle, we've \"patched\" the file to\n> match the new desired result.\n>\n> But what if the file, at lines 15 through 19, reads:\n>\n> we expect the file to\n> look like this\n> and we should add a line\n> and then the text\n>\n> Well, it sure looks like that patch was already applied. We\n> can *guess* that it was in fact already applied, or we can search\n> for lines before or after lines 15 through 19 that read the\n> expected way.\n>\n> Patches can add, remove, or (depending on the kind of patch)\n> change lines (or characters within lines, or whatever: the\n> more general form is \"symbol by symbol, add/subtract/replace\").\n>\n> A *merge*, by contrast, takes two separate sets of patches:\n>\n> * First, there's a \"common base version\": a version both you\n> and they, whoever they were, had that's absolutely 100%]\n> identical in all respects.\n>\n> * Second, there's an \"ours\" version. By comparing the \"base\"\n> version to the \"ours\" version, we find out what *we* changed.\n>\n> * Last, there's a \"theirs\" version. By comparing the \"base\"\n> version to the \"theirs\" version, we find out what *they* changed.\n>\n> This time, if we already have the change at lines 15--19 / 15--20, we'll\n> see that they and we have the *same* change. We can silenly discard\n> their duplicate change! We don't have to guess whether we have their\n> change, or whether the lines moved around somewhat in the file.\n>\n> This same method handles removals (and if they're in the difference\n> format, \"changes\", which are just \"remove and add\" combined into one\n> block).\n>\n> The way \"git apply --3way\" works is that it looks for a text line in the\n> patch of the form \"index ..\" before the diff listing\n> (which has only add and remove, in Git's case). The first hash ID in\n> this pair of hash IDs is the Git-specific unique identifier for the\n> original version of the file. Git then looks in your own Git repository\n> to see if you have that version of the file. If so, that's the\n> \"common base version\".\n>\n> If Git can find the base version this way, Git can then apply the patch\n> diff to the *base* version, which produces the \"theirs\" version,\n> guaranteed, because the change *must* apply to the base. That ID is\n> *unique*, across the entire universe of every file in existence\n> anywhere, in any Git repository.[footnote] If you have that ID, you have\n> *that version* of *that file*.\n>\n> Now that Git has the base version and the \"theirs\" version, Git can do\n> its own three-way merge: diff the base vs your version to see what you\n> changed, and diff the base vs their version to see what they changed.\n> This can still have conflicts, but now at least they will always be in\n> the right places.\n>\n> Chris\n>\n> [footnote] This is clearly nonsense, due to the pigeonhole principle.\n> And yet, Git depends on it successfully (modulo carefully engineered\n> hash collisions, currently possible for SHA-1 but not for SHA-256). With\n> some clever mathematics we can show that the chance of failure of any\n> given Git repository is quite small -- far smaller than the chance that\n> your computer will just randomly explode into flames while you're using\n> it, for instance.\n"}]}