Bug report: AM 3-way patching fails with partial cloning

Bug report: AM 3-way patching fails with partial cloning

[Marius Schiffer]

When applying patches with git am on a repository cloned with 
filter=blob:none, the patching sometimes fails when it can't find the 
required SHA1 information.
Applying the same thing on a normal clone works.
I'm not sure yet what exactly i s missing that is not fetched, but I 
guess git should be able to fetch the missing blobs. I would also be 
very happy to hear workarounds, as I really love git partial cloning.

Using git v2.41.0.

To reproduce:

1. Download this patch: 
https://raw.githubusercontent.com/projectceladon/vendor-intel-utils/master/bsp_diff/common/kernel/linux-intel-lts2021/0007-9p-freezing-aborts-when-use-wait_event_killable.patch

2. Clone this repository: git clone --filter=blob:none 
https://github.com/projectceladon/linux-intel-lts2021

3. Apply the patch: git am -3 
../0007-9p-freezing-aborts-when-use-wait_event_killable.patch


--
Marius

Re: Bug report: AM 3-way patching fails with partial cloning

[Junio C Hamano]

Marius Schiffer <marius@mschiffer.de> writes:

> When applying patches with git am on a repository cloned with
> filter=blob:none, the patching sometimes fails when it can't find the
> required SHA1 information.
> Applying the same thing on a normal clone works.

This is very much expected, especially if your patches are not
generated with --full-index option, because partial clones cannot
on-demand request objects without knowing their full object names to
the promissor remote.  I do not offhand know if "am -3" codepath, if
the full object name is available, is arranged to trigger lazy
fetching of the objects, but nobody sane are sending patches with
the --full-index option to begin with, so that is academic, I would
say.