On Sun, 29 Jun 2008, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes:
>
> > ... In any case, I don't think "git clone" is at
> > all special with respect to GIT_CONFIG.
>
> I think "git init" and "git clone" are very special with respect to
> GIT_CONFIG.
>
> * When "init" is run to create a new repository and initialize it, the
> user would want the initial set of configuration populated in the
> configuration file _for that repository_. There however may be some
> customization that affects the way how "init" operates, which might be
> taken from $HOME/.gitconfig. The meaning of GIT_CONFIG can get fuzzy
> here. Possibilities:
>
> (1) Instead of $HOME/.gitconfig (or /etc/gitconfig), the user might
> want such customizations to be read from the file specified by
> GIT_CONFIG. But the user wants to make the resulting new
> repository usable without any custom GIT_CONFIG set (i.e. its
> $GIT_DIR/config will be the place the configuration is written).
>
> (2) The user may want to create a new repository that cannot be used
> with GIT_CONFIG (for some strange reason), i.e. no $GIT_DIR/config
> for the repository, and GIT_CONFIG is used to specify where that
> separate configuration file for the new repository is. The way
> "init" operates does not come from that configuration file that is
> to be created but from elsewhere.
>
> * When "clone" is run, the same confusion as initializing "init" applies.
> In addition, custom GIT_CONFIG to read customizations for behaviour of
> "init" and "fetch" that is done internally by "clone" would play larger
> role.
>
> * When "init" is run to reinitialize an existing repository, it is not
> special in any way with respect to GIT_CONFIG, compared to other
> commands. The GIT_CONFIG names the configuration for that existing
> repository, so we read from it and write to it.
>
> I personally think the case (2) is a very narrow special case that I do
> not think of any sane reason to even wanting to do so. IOW, "you _could_
> interpret the presense of GIT_CONFIG that the user may want to do so, but
> why?" (1) is also probably not very sensible but it makes more sense.
Actually, (1) has never worked for either clone or init. Init always
obeyed GIT_CONFIG as for where it put the output (in fact git-clone.sh
used GIT_CONFIG to cause git-init to write to the created repo, IIRC).
Clone always replaced GIT_CONFIG with the destination location before it
read any configuration, so it wouldn't see configuration that was in the
user's GIT_CONFIG (or in any pre-existing config file at all).
Historically, these commands don't support (1) and aren't consistant with
each other.
I think it would make sense if there were some way to provide custom
configuration to a particular invocation of "git clone", but GIT_CONFIG as
currently handled by config.c can't do it.
> I think Dscho's original patch would support the semantics (1) and it is
> probably much saner than (2) which is your version does (if I am reading
> the two patches correctly).
My patch makes "git clone" do what "git init; git remote; git fetch" do
with respect to GIT_CONFIG. I don't think this behavior is really useful
for any of those programs or for the combination, but at least having them
match would be consistant. I think the sensible thing would be for
config.c to always write to git_path("config") (or a variable used by
"git config"), and read: git_path("config"), $GIT_CONFIG, ~/.gitconfig,
/etc/gitconfig (in order of decreasing precedence); and further have
builtin-config.c set the "file to write to" variable based on $GIT_CONFIG
or "--file", "--global", or "--system".
But I don't really understand what the purpose of the feature was in the
first place, aside from the narrow case of being able to read and write
files that use the config file format with "git config".
-Daniel
*This .sig left intentionally blank*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
