On Tue, Jan 7, 2014 at 11:46 AM, Otavio Salvador <ota...@ossystems.com.br> wrote: > On Mon, Jan 6, 2014 at 8:10 PM, Saul Wold <s...@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 <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 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... _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
