Re: [PATCH 1/2] clone: respect the settings in $HOME/.gitconfig and /etc/gitconfig

[Junio C Hamano <gitster@pobox.com>]

Daniel Barkalow <barkalow@iabervon.org> 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.

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).