[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 12:16 PM, Koen Kooi <koen at dominion.thruhere.net> wrote:
>
> Op 6 jan. 2014, om 23:10 heeft Saul Wold <sgw at linux.intel.com> het volgende geschreven:
>
>> 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
>
> All the patches I add are git am'able since I use a patch similar to this :)

Cool.

> A big timesaver is to check for  a .git/ in $WORKDIR otherwise git am will try to use a top level git tree (e.g. combo repo) and that's not what we want.

Hmm, yeah, I agree.

However, I do not have time currently for this, nor is this
high-priority for me since it just works for me, and I am happy with
that. Would it be possible to optimize it later?

Failing that, what is the best practice to keep my changes separate
from Yocto? I am referring to changes that are not upstreamed for
whatever reason, like the maintainer saying that here it could be a
performance regression (although non-measured at this point).

Cheers ...