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. 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. My 2c. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core