[yocto] bitbake: git and patch problem

[EXTERNAL van Riel Rob (ENTER, BT-CO/ENG1.1)]

> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield at windriver.com]
> Sent: maandag 5 maart 2018 15:09
> Subject: Re: [yocto] bitbake: git and patch problem
> 
> Out of curiosity .. why is that unexpected, or inconvenient ? I never want a git
> repository to have dirty/unchecked in files, so having the build system apply a
> patch, make sure it is a valid format, signed-off-by and then committed is a good
> thing.

Acually, I wouldn't even want to have the patch in my recipes, and simply commit the code myself, for pretty much the reasons you mention. However, this particular piece of source code is shared between several products, not all of which need the change. Permanently and universally making the relevant change is out, so patch it is (unless I can come up with a better way to force a single define into the build process; I tried adding to CFLAGS, but that wasn't picked up. Others have tangled with this for less trivial changes too).
Added to that is that the yocto system is our de facto development environment, that is, development is typically done on whatever ends up in the tmp/work directories, and pushed to the various version control systems from there. I don't really believe this is the correct way to use yocto, but it's what I have to deal with.
Current behaviour is unexpected, because I would not expect yocto to be the medium for pushing changes back upstream. It is inconvenient, because those git clones are what we use to make changes in, some of which are for the global code base, and in that situation, I would not want to have to roll back an automatic, local change first before getting to work on the global part.

> > Is this expected behaviour, and if so, is there any way to prevent it?
> 
> It is, but you can change what applies the patch.
> 
> Have a look at classes/patch.bbclass, and in particular the variable PATCHTOOL.
> 
> If yours is set to 'git', git will be used. But by default, it is typically set to 'quilt' ..
> so it has been changed from the default in your environment.

Thank you, this may well be just the hint I was looking for. I'll dig in, and see where the trail leads.

Rob