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 <lp...@kde.org> wrote: > On Tue, Jan 7, 2014 at 12:16 PM, Koen Kooi <k...@dominion.thruhere.net> wrote: >> >> Op 6 jan. 2014, om 23:10 heeft Saul Wold <s...@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 <lp...@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 ... _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
