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

[Laszlo Papp]

Hi everyone,

the patch was sent about three weeks ago, and I have not seen any
objections so far.

What is the issue for progressing? Please let me know.

Cheers, L.

On Thu, Jan 9, 2014 at 4:53 PM, Laszlo Papp <lpapp at kde.org> wrote:
> 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 ...