public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
* [PATCH v2 0/1] patch.py: don't apply striplevel to git am command
@ 2020-06-05  1:35 bkylerussell
  2020-06-05  1:35 ` [PATCH v2 1/1] " bkylerussell
  2020-06-05  2:02 ` ✗ patchtest: failure for " Patchwork
  0 siblings, 2 replies; 4+ messages in thread
From: bkylerussell @ 2020-06-05  1:35 UTC (permalink / raw)
  To: openembedded-core; +Cc: wesley.lindauer, Kyle Russell

I thought I had sent this out a month ago, but I can't find it in patchwork,
so I'm resending.  This is an updated patch that addresses feedback on v1, and
should hopefully be more clear.

I've dropped the change to 'git apply' since that wasn't behaving as I originally
thought, then I added a selftest on llvm that demonstrates the issue I'm trying to
resolve.  Without the change in patch.py included here, the selftest that I'm
proposing will fail.

One might argue, "Well, if you change the default PATCHTOOL, you could also
just change your patch SRC_URIs and drop the striplevel parameter."  While
that may be true, the same failure can also be demonstrated using devtool on
llvm without modifying PATCHTOOL at all, since by default devtool also uses
GitApplyTree.  So if you don't consider "modifying a recipe's PATCHTOOL without
also modify its SRC_URI patches" to be a valid workflow, devtool is another
common workflow where this behavior could be encountered.

Hope that helps,
Kyle

Kyle Russell (1):
  patch.py: don't apply striplevel to git am command

 .../llvm/files/0001-Test-new-file.patch        | 17 +++++++++++++++++
 .../recipes-test/llvm/llvm_%.bbappend          |  2 ++
 meta/lib/oe/patch.py                           |  2 +-
 meta/lib/oeqa/selftest/cases/bbtests.py        | 18 ++++++++++++++++++
 4 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 meta-selftest/recipes-test/llvm/files/0001-Test-new-file.patch
 create mode 100644 meta-selftest/recipes-test/llvm/llvm_%.bbappend

-- 
2.17.1


^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: [OE-core] [PATCH 1/1] patch: don't strip GitApplyTree patches
@ 2020-04-27 20:32 bkylerussell
  2020-04-30  0:01 ` [PATCH v2 0/1] patch.py: don't apply striplevel to git am command bkylerussell
  0 siblings, 1 reply; 4+ messages in thread
From: bkylerussell @ 2020-04-27 20:32 UTC (permalink / raw)
  To: Richard Purdie; +Cc: OE-core, wesley.lindauer

[-- Attachment #1: Type: text/plain, Size: 5047 bytes --]

Sorry, it has taken me a while to get back to this.

> If you changed the patch tool to git for those recipes, doesn't it fail
with this patch applied?

Even without my patch, I don't think bash works normally with PATCHTOOL =
"git" since we unpack it from a tgz.  I added PATCHTOOL = "git" to the bash
recipe, and it seems to trash my poky repo's git history instead of the
source in my bash workdir. :( There might be a separate case we should
protect against for that, but I'll have to look at it separately.

llvm looks like the perfect example though, and is much more interesting.
Initially, it actually fails the git am attempt with "fatal: empty ident
name (for <>) not allowed".  I think this might be because git doesn't find
a "From" line first, or something like that.  (If I move Upstream-Status
and Signed-off-by below "From" then git am is happy.). But by default git
am fails, and the first fallback, git apply, doesn't work with my patch as
I expected.  git apply appears to only focus on its current directory,
unlike git am which I think applies from the work-tree root.  I may have
only exercised the git am path initially, but I'll investigate the
difference here further before providing an updated patch.

> We may need to teach GitApplyTree to calculate the difference between the
git repodir and patchdir and adjust the offsets accordingly?

That was the approach I started with, but I couldn't come up with a
scenario where we would end up with an offset other than the default (1)
for commands that work from the repo root (git am).  So maybe the git am
case is the only one that needs to ignore the striplevel, if it truly
always expects to work from the repo root.  Maybe git apply is the case I
unintentionally broke.

When I post a revised patch, I'll also update the commit message subject as
Peter pointed out.

On Thu, Apr 9, 2020 at 6:07 AM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> On Thu, 2020-04-09 at 00:41 -0400, bkylerussell@gmail.com wrote:
> > Don't pass a path removal parameter to git am/git apply since
> GitApplyTree
> > always applies patches from the root of the git repo, not from each
> > individual patchdir (like quilt).
> >
> > GitApplyTree uses `git rev-parse --show-toplevel` to find the root of
> > the repo no matter which patchdir is passed into the GitApplyTree
> instance.
> > In most cases, this works fine when applying patches since the three-way
> > merge can figure out where the patch should be applied to existing files
> > based on the history, even if the file paths are excessively stripped.
> >
> > An exception to this occurs if a patch adds a new file to the repo
> > and a custom ${S} has been set to a subdirectory of the repo such
> > that the patch requires a non-default striplevel parameter.
> >
> > When processed by GitApplyTree, the patch will have its striplevel
> > parameter given to git even though it's applied at the root of the
> > tree.
> >
> > For example, consider a patch that adds a new file src/foo to a repo.
> >
> >   --- /dev/null
> >   +++ b/src/foo
> >   @@ -0,0 +1 @@
> >   +new file test
> >
> > The recipe sets S = "${WORKDIR}/git/src" and the patch is added to
> SRC_URI
> > using "striplevel=2" since the default patch tool, quilt, applies each
> > patch at its patchdir, which defaults to ${S}.
> >
> > When the GitApplyTree patch class is used (for example, through devtool),
> > the root of the repo is passed to git as the work tree, in addition to
> the
> > path removal paramter.  In the case above, GitApplyTree creates
> > ${WORKDIR}/git/foo instead of ${WORKDIR}/git/src/foo.
> >
> > Interestingly enough, you can take a more typical patch example that only
> > changes existing files (instead of adding a new file) and remove the -3
> > argument from the git am/git apply commands issued by GitApplyTree.  In
> > this scenario, the patch will also fail to apply because the path removal
> > arg is still being passed, and the resulting path does not exist.
> >
> > Since GitApplyTree always applies from the root of the repo, it should
> > ignore any striplevel arguments.
>
> I don't follow this argument. We have several recipes in OE-Core which
> set striplevel in SRC_URI (e.g. bash, llvm and a pointless looking one
> in build-compare). If you changed the patch tool to git for those
> recipes, doesn't it fail with this patch applied?
>
> I think you're right and there is an issue here since do_patch assumes
> ${S} is the root for patches whilst git assumes the root of the repo is
> the patch root. If those are different, it will break.
>
> Put another way, I think your patch fixes one case whilst breaking
> others :(.
>
> I'm not sure how we reconcile this. I certainly do not like hoping 'git
> am -3' figures it out. We may need to teach GitApplyTree to calculate
> the difference between the git repodir and patchdir and adjust the
> offsets accordingly?
>
> Cheers,
>
> Richard
>
>
>

[-- Attachment #2: Type: text/html, Size: 5969 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-06-05  2:02 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-06-05  1:35 [PATCH v2 0/1] patch.py: don't apply striplevel to git am command bkylerussell
2020-06-05  1:35 ` [PATCH v2 1/1] " bkylerussell
2020-06-05  2:02 ` ✗ patchtest: failure for " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2020-04-27 20:32 [OE-core] [PATCH 1/1] patch: don't strip GitApplyTree patches bkylerussell
2020-04-30  0:01 ` [PATCH v2 0/1] patch.py: don't apply striplevel to git am command bkylerussell
2020-04-30  0:01   ` [PATCH v2 1/1] " bkylerussell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox