Daniel Barkalow [off-list ref] writes:
There's nothing in the documentation to suggest that you can use
GIT_CONFIG to affect how the old repository is read, or that GIT_CONFIG
doesn't affect the new repository. Actually, as far as I can tell, the
configuration of a repository you're cloning (local or remote) doesn't
matter at all. Note that GIT_DIR and GIT_WORK_TREE refer to the new repo,
so it would be surprising for GIT_CONFIG to refer to the old one.
There was a bit of confusion in this discussion.
GIT_DIR the user may have in the environment may refer to the
old reopsitory before "git clone" is invoked, but it should not
matter at all, as the origin of the cloning comes from the
command line and that is where we will read from. The scripted
version sets GIT_DIR for our own use to point at the new
repository upfront and exports it, so we are safe from bogus
GIT_DIR value the user may have in the environment.
GIT_WORK_TREE naming the new repository feels Ok, as you do not
care about the work tree of the original tree when cloning, and
you may want to have a say in where the work tree associated
with the new repository should go.
GIT_CONFIG the user may have will refer to the old repository
before "git clone" is invoked, as there is no new repository
built yet. But clone does not read from the old config, so "you
can use GIT_CONFIG to read from old repository" may be true, but
it does not matter. We won't use it (we do _not_ want to use
it) to read from the old configuration file.
We would however want to make sure that we write to the correct
configuration file of the new repository and not some random
other place, and that's where the environment variable in the
scripted version comes into the picture.
In the scripted version, the only way to make sure which exact
configuration file is updated is to set and export GIT_CONFIG
when running "git config", so there are a few places that does
exactly that (e.g. call to git-init and setting of core.bare).
Unfortunately many codepaths in the scripted version are utterly
careless (e.g. setting of remote."$origin".fetch); they should
make sure that they protect themselves against GIT_CONFIG the
user may have in the environment that point at random places.
My current design is to collect some initial information, create
directories, and then set the work tree and git dir. Then we run fetch,
configure things, etc., in the new context.
That sounds like a clean design to me.
On Tue, 26 Feb 2008, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
There's nothing in the documentation to suggest that you can use
GIT_CONFIG to affect how the old repository is read, or that GIT_CONFIG
doesn't affect the new repository. Actually, as far as I can tell, the
configuration of a repository you're cloning (local or remote) doesn't
matter at all. Note that GIT_DIR and GIT_WORK_TREE refer to the new repo,
so it would be surprising for GIT_CONFIG to refer to the old one.
There was a bit of confusion in this discussion.
GIT_DIR the user may have in the environment may refer to the
old reopsitory before "git clone" is invoked, but it should not
matter at all, as the origin of the cloning comes from the
command line and that is where we will read from. The scripted
version sets GIT_DIR for our own use to point at the new
repository upfront and exports it, so we are safe from bogus
GIT_DIR value the user may have in the environment.
Huh. I think there's a comment in some test or somewhere that made me
think that "GIT_DIR=dest.git git clone foo" would write to dest.git
instead of ./foo/.git, but your description here is accurate.
GIT_WORK_TREE naming the new repository feels Ok, as you do not
care about the work tree of the original tree when cloning, and
you may want to have a say in where the work tree associated
with the new repository should go.
We currently definitely support "GIT_WORK_TREE=work git clone something",
pretty much explicitly on line 235 of git-clone.sh.
GIT_CONFIG the user may have will refer to the old repository
before "git clone" is invoked, as there is no new repository
built yet. But clone does not read from the old config, so "you
can use GIT_CONFIG to read from old repository" may be true, but
it does not matter. We won't use it (we do _not_ want to use
it) to read from the old configuration file.
We would however want to make sure that we write to the correct
configuration file of the new repository and not some random
other place, and that's where the environment variable in the
scripted version comes into the picture.
In the scripted version, the only way to make sure which exact
configuration file is updated is to set and export GIT_CONFIG
when running "git config", so there are a few places that does
exactly that (e.g. call to git-init and setting of core.bare).
Unfortunately many codepaths in the scripted version are utterly
careless (e.g. setting of remote."$origin".fetch); they should
make sure that they protect themselves against GIT_CONFIG the
user may have in the environment that point at random places.
Since it sets GIT_DIR, it also could simply unset GIT_CONFIG, and then
everything would just write to the config file for the new GIT_DIR. On the
other hand, if you have GIT_CONFIG exported in your environment, and you
set up a repository with "git clone", and clone unsets or overrides
GIT_CONFIG, then your new repository will immediately be unusable, because
clone will set up the config file inside the new repository, but nothing
you run after that will look in the new repository, since everything else
obeys the GIT_CONFIG you still have set.
On the other hand, I don't see why any git command other than "git config"
(run my the user directly) has any business looking at GIT_CONFIG, since
it's only mentioned in the man page for git-config, and not in general for
configuration, the wrapper, or other programs.
-Daniel
*This .sig left intentionally blank*