From: Mark Nicholson <email@example.com>
To: "firstname.lastname@example.org" <email@example.com>
Subject: bug found in `git apply` sub-command
Date: Mon, 22 Feb 2021 19:19:36 +0000 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
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):
3. Get a 'git format-patch' of this commit:
(this is the commit which causes the fault!)
git format-patch 3e0de271fff77a..ccf74128d66ce9
and it produced
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.
git version 2.30.0
no commit associated with this build
uname: Linux 5.10.15-172.current #1 SMP PREEMPT Fri Feb 12 16:35:57 UTC 2021
compiler info: gnuc: 9.3
libc info: glibc: 2.31
$SHELL (typically, interactive shell): /bin/bash
reply other threads:[~2021-02-22 19:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).