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
