tree 55c72387e3a17f2099da5c2303f078fe19dfc412
parent befd89b0154072d7f511fbb20732aabd81218226
author Rupert Swarbrick <rswarbrick@lowrisc.org> 1590682660 +0100
committer Philipp Wagner <mail@philipp-wagner.com> 1590684097 +0100

[util] Correctly cope with patch_dir and no mapping in vendor.py

This was broken with my recent patch to add "mapping" support. The fix
passes a boolean flag to Mapping1.make_default saying "please add a
relative patch directory of '.' to the dummy mapping entry you make".

This patch also fixes how we run "git apply" to apply the patches.
It turns out that if you run

   cd subdir/in/repo
   git apply my.patch

then the paths in my_path are interpreted relative to the root of the
repository (and anything that applies to a file outside of
subdir/in/repo is skipped).

Before the recent vendoring changes, we applied the patches before
copying into the target repository. So it was something like

   git clone git://something /tmp/something
   (cd /tmp/something; git apply -p1 /path/to/my.patch)
   cp /tmp/something/* vendor/something

I'm not sure this would work with only_subdir, but it definitely did
work correctly if we were copying from the top of the vendored repo.

The recent vendoring changes alter things to:

   git clone git://something /tmp/something
   cp /tmp/something/* vendor/something
   (cd vendor/something; git apply -p1 /path/to/my.patch)

This doesn't do what you want, because the paths in the patch look
like a/myfile.c rather than a/vendor/something/myfile.c (and the hunks
all get skipped).

We can fix things up again by using the --directory argument to git
apply, which works a bit like you might expect changing directory to
vendor/something would work and changes how the patch paths are
interpreted.

Signed-off-by: Rupert Swarbrick <rswarbrick@lowrisc.org>