git/list[1] front-page[2] threads[3] people[4] search[5] about
 

bug found in `git apply` sub-command

From
MNMark Nicholson <mark.j.nicholson@oracle.com>
Date
Feb 22, 2021, 19:19 UTC
Message-ID
<3d292e1d7c266eab456a5b9a0587efe702976533.camel@oracle.com>

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)
1. Clone torvalds/master
2. Checkout a branch at this commit (the commit BEFORE the problematic one to
stage the patch so it would work):
        3e0de271fff77abb933f1b69c213854c3eda9125
3. Get a 'git format-patch' of this commit:
        ccf74128d66ce937876184ad55db2e0276af08d3
        (this is the commit which causes the fault!)
   I did:
      git format-patch 3e0de271fff77a..ccf74128d66ce9
   and it produced
      0001-sched-topology-Assert-non-NUMA-topology-masks-don-t-.patch
4. Try to `git apply` the format-patch generated:
    git apply 0001-sched-topology-Assert-non-NUMA-topology-masks-don-t-.patch
What did you expect to happen? (Expected behavior)

I expected it to apply the patch cleanly. AFAICT, it is a VALID patch which is already committed to Linux.

What happened instead? (Actual behavior)
It gives me the error message:

error: patch fragment without header at line 58: @@ -465,6 +465,9 @@ void update_siblings_masks(unsigned int cpuid)

What's different between what you expected and what actually happened?

It shouldn't raise an error on applying this patch; its complaining about a patch-fragment _inside_ the message.

Anything else you want to add:
My curiosity was raised since simply doing:
   git am 0001-sched-topology-Assert-non-NUMA-topology-masks-don-t-.patch
applies _exactly_ the same patch without any guff.

I would _really_ expect `git am` and `git apply` to work in exactly the same way, except for the expected difference of the actual commit. The "patching" part should work identically.

I tested some other behaviours and `git cherry-pick` of the offending commit works fine. (Although, I suspect that this does not actually "parse" the commit message, so probably not and apples-to-apples comparison.)

I looked at this patch and in the "message" section, it contains a patch- fragment. Moreover, that patch-fragment is left-justified.

A simple fix to avoid this problem is indenting the message-embedded patch- fragment by a couple spaces.

It appears that `git apply`, as it is parsing the message triggers on the patch- fragment INSIDE the message section. Comparatively, `git am` does NOT trigger and both patches and commits it without issue.

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.30.0 cpu: x86_64 no commit associated with this build sizeof-long: 8 sizeof-size_t: 8 shell-path: /bin/sh uname: Linux 5.10.15-172.current #1 SMP PREEMPT Fri Feb 12 16:35:57 UTC 2021 x86_64 compiler info: gnuc: 9.3 libc info: glibc: 2.31 $SHELL (typically, interactive shell): /bin/bash

[Enabled Hooks]
Message 1 of 1 in “bug found in `git apply` sub-command”
  1. Mark NicholsonFeb 22, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.