Re: Overriding ~/.gitconfig using GIT_CONFIG

[Richard Purdie <rpurdie@rpsys.net>]

On Mon, 2011-08-29 at 20:10 -0700, David Aguilar wrote:
> On Mon, Aug 29, 2011 at 01:16:06PM +0100, Richard Purdie wrote:
> > On Sun, 2011-08-28 at 06:05 -0700, David Aguilar wrote:
> > > On Fri, Aug 12, 2011 at 09:44:13PM +0100, Richard Purdie wrote:
> > > > My problem isn't that I want to specify a specific .gitconfig file, I
> > > > just need it to ignore the one in $HOME. I'm happy for the .git/config
> > > > file to be used, in fact I need it to be.
> > > 
> > > If you're writing a tool then it should restrict itself to
> > > git's plumbing commands.  You should be able to do just about
> > > anything without needing to worry about differences in
> > > configuraiton.  Git commands almost always provide a way to
> > > override configuration through the use of flags.
> > > 
> > > The plumbing commands are listed in the main git manpage.
> > > See "Low-level commands (plumbing)" here:
> > > http://www.kernel.org/pub/software/scm/git/docs/
> > > 
> > > What is the specific problem solved by overriding the
> > > configuration?  It may be possible to solve it without needing
> > > to get too complicated.
> > 
> > I'm not sure writing my own porcelain makes sense in this case.
> 
> True...  luckily we don't have to go that far.
> 
> > The tool in question is a build system which is primarily interested in
> > building software. Sometimes the software we want to build is "bleeding
> > edge" and hence rather than download tarballs, we want to interact
> > directly with SCMs like git to obtain it.
> > 
> > The commands I'm using are the likes of "git clone" and "git fetch"
> > although we do use commands listed under the plumbing section too such
> > as ls-remote and read-tree. We do "cache" checkouts and support
> > automatically noticing changes and updating/building.
> > 
> > What I do want to be able to say is "ignore whatever the user might have
> > put in their ~/.gitconfig file" since I've open bug reports about people
> > putting things in there that break builds.
> > 
> > The fetch/clone commands do what I need, apart from being influenced by
> > userconfig so reimplementing them myself doesn't seem like a good
> > approach.
> 
> This is what we're interested in.
> 
> Do you have the specifics of exactly what in the user
> ~/.gitconfig file broke the build?
> 
> What I'm suggesting is that there's probably a way to avoid
> the user-dependent behavior by being explicit on
> the command-line.
> 
> Specifically regarding fetch -- if you're doing "git fetch"
> and relying on the configuration then we can probably come
> up with a more explicit fetch command that has an explicit
> and predictable behavior independent of the user's
> configuraiton.
> 
> Using the explicit form of the command can make the build system
> more robust.
> 
> Let us know what you're cooking, it sounds interesting.

We've gone through several iterations of this but as things stand now,
to initially clone things we're doing:

git clone --bare --mirror <url> <dir>

but if we already have some existing clone we'd update with:

git remote prune origin
git remote rm origin
git remote add --mirror origin <url>
git fetch --all -t

I have a strong suspicion that the fetch --all doesn't do us any favours
since if the user defines other remotes in their local config it will
also fetch them. We could probably change this to be "git fetch origin
-t" which would be safer however the .gitconfig file that someone
reported causing problems actually defined an origin remote. I don't
want to debate whether that is sane or not, I just want to be 100% sure
we work regardless of what the user may have defined.

For reference, the reasons for the remote commands above is to be 100%
sure that we fetch the right thing if <url> has changed, or if upstream
has deleted any branches in incompatible ways. We've tried not using any
remotes at all but that seems to bring its own set of problems as we
have seen issues with fetch not downloading everything from the upstream
repo (which is what we need since this is a cache/mirror copy). We ended
up needing to be very precise about what we wanted.

When we actually come to build something we make a referenced clone that
contains an actual checkout with the commands:

git clone -s -n <dir> <dir>
git checkout <revision>

which has the nice effect of being kind on disk space and fast :).

Or in some cases where we only want a specific subdirectory:

git read-tree <revision>:<subdir>
git checkout-index -q -f -a

which is fairly evil and leaves the tree in a nasty state but its what
some people need.

In case you're interested, the code in question is part of a tool called
bitbake and is one of several different fetcher modules:

http://git.openembedded.org/cgit.cgi/bitbake/tree/lib/bb/fetch2/git.py

So if a user has an origin remote in their .gitconfig, can we ignore it?

Cheers,

Richard

-- 
Linux Foundation
http://www.yoctoproject.org/