From: Knut Omang <knut.omang@oracle.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: Bug: 'git config --local user.email=<alt.email>' fails silently?
Date: Sun, 02 Apr 2017 09:53:39 +0200 [thread overview]
Message-ID: <1491119619.5830.19.camel@oracle.com> (raw)
In-Reply-To: <20170402073823.tudnfftbxaa6jdo5@sigill.intra.peff.net>
On Sun, 2017-04-02 at 03:38 -0400, Jeff King wrote:
> On Sun, Apr 02, 2017 at 07:47:23AM +0200, Knut Omang wrote:
>
> > From the documentation I would have expected
> >
> > git config --local user.email=alt.email@alt.domain
> >
> > to create a section
> >
> > [user]
> > email=alt.email@alt.domain
> >
> > in the local .git/config.
>
> When it sees one argument, git-config treats that argument as a key to
> be retrieved. When given two, the second is a value to be set. E.g.:
>
> $ git config foo.bar
> $ git config foo.bar some-value
> $ git config foo.bar
> some-value
>
> So your command was interpreted as a request to fetch the value, which
> doesn't exist.
>
> > Instead it returns status 1 with no error message.
>
> Hopefully that explains the response you saw; we do not emit an error
> message when a key isn't found, which makes it easy for scripts to do
> things like:
>
> value=$(git config foo.bar || echo default-value)
>
> without being unnecessarily noisy.
>
> Usually we'd catch an error like yours and complain, because the key is
> syntactically invalid ("=" is not generally allowed in key names):
>
> $ git config foo.bar=some-value
> error: invalid key: foo.bar=some-value
>
> But your argument actually _is_ a syntactically valid key, because of
> the dots. In a three-level key like "one.two.three", the second level
> subsection is allowed to contain any character (including "=" and more
> dots). So your "user.email=alt.email@alt.domain" tries to look up the
> config represented by:
>
> [user "email=alt.email@alt"]
> domain
>
> Which of course did not exist.
>
> > Is this intentional?
>
> Yes, everything is working as intended. The documentation in
> git-config(1) seems to be quite poor at describing the various operating
> modes, though.
Ah - I see!
Thanks for the quick answer and excellent explanation,
and sorry for the confusion - I should know well that config takes
the write argument after a blank.
I think I'll go and get myself another cup of coffee
before I ask more questions anywhere...
Regards,
Knut
>
> -Peff
prev parent reply other threads:[~2017-04-02 7:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-02 5:47 Bug: 'git config --local user.email=<alt.email>' fails silently? Knut Omang
2017-04-02 7:38 ` Jeff King
2017-04-02 7:53 ` Knut Omang [this message]
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=1491119619.5830.19.camel@oracle.com \
--to=knut.omang@oracle.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.