[OE-core] [PATCH] lib/oe/patch.py: Prefer "git am" over "git apply" when applying git patches

[Laszlo Papp]

On Tue, Jan 7, 2014 at 11:46 AM, Otavio Salvador
<otavio at ossystems.com.br> wrote:
> On Mon, Jan 6, 2014 at 8:10 PM, Saul Wold <sgw at linux.intel.com> wrote:
>> On 12/31/2013 06:18 AM, Laszlo Papp wrote:
>>>
>>> Ping?
>>>
>>> Alternatively, the system could also have an option for further
>>> fine-tuning what to do with git patches
>>>
>>> On Tue, Dec 24, 2013 at 12:44 PM, Laszlo Papp <lpapp at kde.org> wrote:
>>>>
>>>> It is better to use "git am" when possible to preserve the commit
>>>> messages and
>>>> the mail format in general for patches when those are present. A typical
>>>> use
>>>> case is when developers would like to keep the changes on top of the
>>>> latest
>>>> upstream, and they may occasionally need to rebase. This is not possible
>>>> with
>>>> "git diff" and "diff" generated patches.
>>>>
>>>> Since this is not always the case, the fallback would be the "git apply"
>>>> operation which is currently available.
>>>>
>> Looking at this, is it possible to detect a git patch and only then use git
>> am?  Since most of the patches carried in oe-core and other layers the 'git
>> am' will typically fail and increase the build time since it will have to
>> re-run the git apply, we don't want to had more forking and work in the main
>> hot path.
>>
>> I am not the expert in this, neither is RP, so maybe Chris can comment
>> further.
>
> I am not sure it'd buy us a lot trying to detect it; in fact using git
> am patches easy rework, rebase and upstreaming of those.

+1

> To detect it, we'd need to parse the file somehow and I am unsure it
> would be faster than just try to apply it.

Agree; it may even be slower. I think it could be separated out later
into a custom option if any performance issue comes up. IMO, it is a
reasonable assumption if the patchtool set is git, then it is a git
patch, not raw diff...