Re: [Buildroot] [PATCH] support/download/git: disable global & system config

[John Keeping <john@metanate.com>]

On Mon, Aug 15, 2022 at 01:41:43PM +0200, Yann E. MORIN wrote:
> On 2022-08-15 11:46 +0100, John Keeping spake thusly:
> > On Sun, Aug 14, 2022 at 12:11:43AM +0200, Yann E. MORIN wrote:
> > > On 2022-08-11 14:45 +0100, John Keeping spake thusly:
> > > > The build environment should be isolated from the host system as much as
> > > > possible to keep the build reproducible.  Git's global config (usually
> > > > ~/.gitconfig) and system config (/etc/gitconfig) can affect the
> > > > behaviour of all Git operations, so should be disabled.
> > > While I appreciate the reasoning and example, there are valid cases
> > > where we do want to use (at least) the user's settings, [...]
> > What do you thing about adding a config option to specify the global
> > gitconfig file to use?
> [--SNIP--]
> > 	eval ${BR2_GIT_CONFIG_GLOBAL:+GIT_CONFIG_GLOBAL=\'${BR2_GIT_CONFIG_GLOBAL}\'} \
> > 		GIT_DIR="${git_cache}/.git" ${GIT} "${@}"
> 
> Honestly, I don't think the issue warrants extra complexity.
> 
> For your git-lfs example, we would notice a missing FO_GIT_LFS fairly
> quickly, thanks to the autobuilders. So this is not a big issue for
> packages in upstream Buildroot; for br2-external trees, this is most
> probably not an issue either: either all developpers ona project have
> the same settings, or they are using a sane build environment, or they
> would also notice, so this is not very important.
> 
> Hwever, there are settings that we would probably want to always
> disable, like line-ending mangling (core.autocrlf or gitattributes) or
> other keyword replacement (gitattributes 'ident' or 'filter'...). But
> then, we haven't had much report about such failures, if at all, so this
> does not look like a problem in practice.
> 
> So, I still don't think we need to add complexity to solve this issue.
> If we can get something really simple, that's OK, but no nuclear
> powerplant please. ;-)

I think the above is as simple as it gets, the only alternative I can
see is explicit listing either permitted or banned config variables.

But it turns out that $GIT_CONFIG_GLOBAL was only added last year (in
Git v2.32) so it's not available everywhere yet and we can't rely on the
installed Git supporting this.

I'm dropping this now because it looks like the complexity is going to
outweigh the benefit for any approach that doesn't use
$GIT_CONFIG_GLOBAL.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot