From: Jeff King <peff@peff.net>
To: Alexander Kuleshov <kuleshovmail@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [PATCH RFC] init-db: introduce new -c/--config option
Date: Wed, 25 Mar 2015 14:39:59 -0400 [thread overview]
Message-ID: <20150325183959.GA16989@peff.net> (raw)
In-Reply-To: <CANCZXo56RY18xKJbQoU=VRYApnKfy6e9ieu8munNsF6WB6YWYg@mail.gmail.com>
On Thu, Mar 26, 2015 at 12:30:13AM +0600, Alexander Kuleshov wrote:
> I'm not sure about two things:
>
> 1. Is there any way to do this with the current git? At least i didn't
> find how to do it, so decided to write this patch.
> If there is already ability to do the same without this patch, please
> let me know.
The reason we originally added "-c" to clone and not init is that clone
performs several other follow-on actions after the repository is
initialized. For example, you might want to run:
git clone -c core.autocrlf=true ...
to have that option in place before clone checks out files to the
working tree. There is no direct way to have "git init" set the config
for you, but there is no harm in doing:
git init
git config core.autocrlf=true
because init returns control to you immediatel.
> 2. Now current patch overwrite the value of the configuration option
> from config,
> if there is given option with the same key. For example, when we do git init,
> .git/config contains core.filemode = true. If we will pass
> core.filemode = false with this patch to git init,
> there will be core.filemode = false in the .git/config. So, I'm not
> sure about it.
> I looked on git clone -c/--config, it just adds the same option to the
> .git/config, but it looks strange to me....
Most options, when there are multiple present, will use the last-seen
value (core.filemode is one of these, so having it there twice means the
second one takes precedence). Some options form a list (e.g., fetch
refspecs). So if you run:
git clone -c remote.origin.fetch=refs/notes/*:refs/notes/* ...
you add a new refspec, but do not replace the default one to fetch the
actual branches. The knowledge of which config keys are which is known
only to the config callbacks, so it is generally safer for generic
config-munging code to add a potentially overriding key (the downside is
that you cannot use "-c" to "clear" a list-like key, but the inability
to do that is a failing of the config code in general).
-Peff
next prev parent reply other threads:[~2015-03-25 18:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 18:22 [PATCH RFC] init-db: introduce new -c/--config option Alexander Kuleshov
2015-03-25 18:30 ` Alexander Kuleshov
2015-03-25 18:39 ` Jeff King [this message]
2015-03-25 20:30 ` Eric Sunshine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150325183959.GA16989@peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=kuleshovmail@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).