The patch extends git config --file interface to allow read config from
stdin.

Editing stdin or setting value in stdin is an error.

Include by absolute path is allowed in stdin config, but not by relative
path.
Signed-off-by: NKirill A. Shutemov <kirill@shutemov.name>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When you run "git config --int", the maximum size of integer
you get depends on how git was compiled, and what it
considers to be an "int".

This is almost useful, because your scripts calling "git
config" will behave similarly to git internally. But relying
on this is dubious; you have to actually know how git treats
each value internally (e.g., int versus unsigned long),
which is not documented and is subject to change. And even
if you know it is "unsigned long", we do not have a
git-config option to match that behavior.

Furthermore, you may simply be asking git to store a value
on your behalf (e.g., configuration for a hook). In that
case, the relevant range check has nothing at all to do with
git, but rather with whatever scripting tools you are using
(and git has no way of knowing what the appropriate range is
there).

Not only is the range check useless, but it is actively
harmful, as there is no way at all for scripts to look
at config variables with large values. For instance, one
cannot reliably get the value of pack.packSizeLimit via
git-config. On an LP64 system, git happily uses a 64-bit
"unsigned long" internally to represent the value, but the
script cannot read any value over 2G.

Ideally, the "--int" option would simply represent an
arbitrarily large integer. For practical purposes, however,
a 64-bit integer is large enough, and is much easier to
implement (and if somebody overflows it, we will still
notice the problem, and not simply return garbage).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If we try to parse an integer config argument and get a
number outside of the representable range, we die with the
cryptic message: "bad config value for '%s'".

We can improve two things:

  1. Show the value that produced the error (e.g., bad
     config value '3g' for 'foo.bar').

  2. Mention the reason the value was rejected (e.g.,
     "invalid unit" versus "out of range").

A few tests need to be updated with the new output, but that
should not be representative of real-world breakage, as
scripts should not be depending on the exact text of our
stderr output, which is subject to i18n anyway.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Using the same urlmatch_config_entry() infrastructure, add a new
mode "--get-urlmatch" to the "git config" command, to learn values
for the "virtual" two-level variables customized for the specific
URL.

    git config [--<type>] --get-urlmatch <section>[.<key>] <url>

With <section>.<key> fully specified, the configuration data for
<section>.<urlpattern>.<key> for <urlpattern> that best matches the
given <url> is sought (and if not found, <section>.<key> is used)
and reported.  For example, with this configuration:

    [http]
        sslVerify
    [http "https://weak.example.com"]
        cookieFile = /tmp/cookie.txt
        sslVerify = false

You would get

    $ git config --bool --get-urlmatch http.sslVerify https://good.example.com
    true
    $ git config --bool --get-urlmatch http.sslVerify https://weak.example.com
    false

With only <section> specified, you can get a list of all variables
in the section with their values that apply to the given URL.  E.g

    $ git config --get-urlmatch http https://weak.example.com
    http.cookiefile /tmp/cookie.txt
    http.sslverify false
Helped-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The config-editing code used by "git config var value" is
built around the regular config callback parser, whose only
triggerable item is an actual key. As a result, it does not
know anything about section headers, which can result in
unnecessarily ugly output:

  1. When we delete the last key in a section, we should be
     able to delete the section header.

  2. When we add a key into a section, we should be able to
     reuse the same section header, even if that section did
     not have any keys in it already.

Unfortunately, fixing these is not trivial with the current
code. It would involve the config parser recording and
passing back information on each item it finds, including
headers, keys, and even comments (or even better, generating
an actual in-memory parse-tree).

Since these behaviors do not cause any functional problems
(i.e., the resulting config parses as expected, it is just
uglier than one would like), fixing them can wait until
somebody feels like substantially refactoring the parsing
code. In the meantime, let's document them as known issues
with some tests.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When given a variable without a value, such as '[section] var' and
asking git-config to treat it as a path, git_config_pathname returns
an error and doesn't modify its output parameter. show_config assumes
that the call is always successful and sets a variable to indicate
that vptr should be freed. In case of an error however, trying to do
this will cause the program to be killed, as it's pointing to memory
in the stack.

Detect the error and return immediately to avoid freeing or accessing
the uninitialed memory in the stack.
Signed-off-by: NCarlos Martín Nieto <cmn@elego.de>
Acked-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If git-config is asked for a single value, it will complain
and exit with an error if it finds multiple instances of
that value. This is unlike the usual internal config
parsing, however, which will generally overwrite previous
values, leaving only the final one. For example:

  [set a multivar]
  $ git config user.email one@example.com
  $ git config --add user.email two@example.com

  [use the internal parser to fetch it]
  $ git var GIT_AUTHOR_IDENT
  Your Name <two@example.com> ...

  [use git-config to fetch it]
  $ git config user.email
  one@example.com
  error: More than one value for the key user.email: two@example.com

This overwriting behavior is critical for the regular
parser, which starts with the lowest-priority file (e.g.,
/etc/gitconfig) and proceeds to the highest-priority file
($GIT_DIR/config). Overwriting yields the highest priority
value at the end.

Git-config solves this problem by implementing its own
parsing. It goes from highest to lowest priorty, but does
not proceed to the next file if it has seen a value.

So in practice, this distinction never mattered much,
because it only triggered for values in the same file. And
there was not much point in doing that; the real value is in
overwriting values from lower-priority files.

However, this changed with the implementation of config
include files. Now we might see an include overriding a
value from the parent file, which is a sensible thing to do,
but git-config will flag as a duplication.

This patch drops the duplicate detection for git-config and
switches to a pure-overwrite model (for the single case;
--get-all can still be used if callers want to do something
more fancy).

As is shown by the modifications to the test suite, this is
a user-visible change in behavior. An alternative would be
to just change the include case, but this is much cleaner
for a few reasons:

  1. If you change the include case, then to what? If you
     just stop parsing includes after getting a value, then
     you will get a _different_ answer than the regular
     config parser (you'll get the first value instead of
     the last value). So you'd want to implement overwrite
     semantics anyway.

  2. Even though it is a change in behavior for git-config,
     it is bringing us in line with what the internal
     parsers already do.

  3. The file-order reimplementation is the only thing
     keeping us from sharing more code with the internal
     config parser, which will help keep differences to a
     minimum.

Going under the assumption that the primary purpose of
git-config is to behave identically to how git's internal
parsing works, this change can be seen as a bug-fix.
Signed-off-by: NJeff King <peff@peff.net>

We check that we can "--get-all" a multi-valued variable,
but we do not actually confirm that the output is sensible.
Doing so reveals that it works fine, but this will help us
ensure we do not have regressions in the next few patches,
which will touch this area.
Signed-off-by: NJeff King <peff@peff.net>

This test checks that git-config fails for an ambiguous
"get", but we check the exact same thing 3 tests beforehand.
Signed-off-by: NJeff King <peff@peff.net>

The t1300 test script is quite old, and does not use our
modern techniques or styles. This patch updates it in the
following ways:

  1. Use test_cmp instead of cmp (to make failures easier to
     debug).

  2. Use test_cmp instead of 'test $(command) = expected'.
     This makes failures much easier to debug, and also
     makes sure that $(command) exits appropriately.

  3. Use test_must_fail (easier to read, and checks more
     rigorously for signal death).

  4. Write tests with the usual style of:

       test_expect_success 'test name' '
               test commands &&
	       ...
       '

     rather than one-liners, or using backslash-continuation.
     This is purely a style fixup.

There are still a few command happening outside of
test_expect invocations, but they are all innoccuous system
commands like "cat" and "cp". In an ideal world, each test
would be self sufficient and all commands would happen
inside test_expect, but it is not immediately obvious how
the grouping should work (some of the commands impact the
subsequent tests, and some of them are setting up and
modifying state that many tests depend on). This patch just
picks the low-hanging style fruit, and we can do more fixes
on top later.
Signed-off-by: NJeff King <peff@peff.net>

Use the i18n-specific test functions in test scripts for parseopt tests.
This issue was was introduced in v1.7.10.1-488-g54e6d:

    54e6d i18n: parseopt: lookup help and argument translations when showing usage

and been broken under GETTEXT_POISON=YesPlease since.
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

You can feed junk to "git config --rename-section", which
will result in a config file that git will not even parse
(so you cannot fix it with git-config). We already have
syntactic sanity checks when setting a variable; let's do
the same for section names.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A section in a config file with a missing "]" reports the next line
as bad, same goes to a value with a missing end quote.

This happens because the error is not detected until the end of the
line, when line number is already increased. Fix this by decreasing
line number by one for these cases.
Signed-off-by: NMartin Stenberg <martin@gnutiken.se>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The git-config command sometimes operates on the default set
of config files (either reading from all, or writing to repo
config), and sometimes operates on a specific file. In the
latter case, we set the magic global config_exclusive_filename,
and the code in config.c does the right thing.

Instead, let's have git-config use the "advanced" variants
of config.c's functions which let it specify an individual
filename (or NULL for the default). This makes the code a
lot more obvious, and fixes two small bugs:

  1. A relative path specified by GIT_CONFIG=foo will look
     in the wrong directory if we have to chdir as part of
     repository setup. We already handle this properly for
     "git config -f foo", but the GIT_CONFIG lookup used
     config_exclusive_filename directly. By dropping to a
     single magic variable, the GIT_CONFIG case now just
     works.

  2. Calling "git config -f foo --edit" would not respect
     core.editor. This is because just before editing, we
     called git_config, which would respect the
     config_exclusive_filename setting, even though this
     particular git_config call was not about looking in the
     user's specified file, but rather about loading actual
     git config, just as any other git program would.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Breaks in a test assertion's && chain can potentially hide failures from
earlier commands in the chain by adding " &&" at the end of line to the
commands that need them.
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Acked-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since some tests before test number 79 ("quoting") are skipped, .git/config
does not exist and 'rm .git/config' fails. Fix this particular case.

While at it, move other instance of 'rm .git/config' that occur in this
file inside the test function to document that the test cases want to
protect themselves from remnants of earlier tests.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We should be able to ask for a config value both by its
canonical all-lowercase name (as git does internally), as
well as by random mixed-case (which will be canonicalized by
git-config for us).

Subsections are a tricky point, though. Since we have both

  [section "Foo"]

and

  [section.Foo]

you might want git-config to canonicalize the subsection or
not, depending on which you are expecting. But there's no
way to communicate this; git-config sees only the key, and
doesn't know which type of section name will be in the
config file.

So it must leave the subsection intact, and it is up to the
caller to provide a canonical version of the subsection if
they want to match the latter form.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This is a very old script, and did a lot of:

  echo whatever >expect
  git config foo bar
  test_expect_success 'cmp .git/config expect'

which meant that we didn't actually check that the call to
git-config succeeded. Fix this, and while we're at it,
modernize the style to use test_cmp.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The previous logic in show_config was to print the delimiter when the
value was set, but Boolean variables have an implicit value "true" when
they appear with no value in the config file. As a result, we got:

git_Config        --get-regexp '.*\.Boolean'	#1. Ok: example.boolean
git_Config --bool --get-regexp '.*\.Boolean'	#2. NO: example.booleantrue

Fix this by defering the display of the separator until after the value
to display has been computed.
Reported-by: NBrian Foster <brian.foster@maxim-ic.com>
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We already check for an empty key on the left side of an
equals, but we would segfault if there was no content at
all.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The error handling for git_config is somewhat confusing. We
collect errors from running git_config_from_file on the
various config files and carefully pass them back up. But
the two odd things are:

  1. We actually die on most errors in git_config_from_file.
     In fact, the only error we actually pass back up is if
     fopen() fails on the file.

  2. Most callers of git_config do not check the error
     return at all, but will continue if git_config reports
     an error.

When the code for "git -c core.foo=bar" was added, it
dutifully passed errors up the call stack, only for them to
be eventually ignored. This makes it inconsistent with the
file-parsing code, which will die when it sees malformed
config. And it's somewhat unsafe, because it means an error
in parsing a typo like:

  git -c clean.requireforce=ture clean

will continue the command, ignoring the config the user
tried to give.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If you do something like:

  git -c core.foo="value with = in it" ...

we would split your option on "=" into three fields and
throw away the third one. With this patch we correctly take
everything after the first "=" as the value (keys cannot
have an equals sign in them, so the parsing is unambiguous).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The handle_options() function advances the base of the argument array and
returns the number of arguments it used. The caller in handle_alias()
wants to reallocate the argv array it passes to this function, and
attempts to do so by subtracting the returned value to compensate for the
change handle_options() makes to the new_argv.

But handle_options() did not correctly count when "-c <config=value>" is
given, causing a wrong pointer to be passed to realloc().

Fix it by saving the original argv at the beginning of handle_options(),
and return the difference between the final value of argv, which will
relieve the places that move the array pointer from the additional burden
of keeping track of "handled" counter.

Noticed-by: Kazuki Tsujimoto
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Previously we parsed GIT_CONFIG_PARAMETERS lazily into a
linked list, and then checked that list during future
invocations of git_config. However, that ignores the fact
that the environment variable could change during our run
(e.g., because we parse more "-c" as part of an alias).

Instead, let's just re-parse the environment variable each
time. It's generally not very big, and it's no more work
than parsing the config files, anyway.

As a bonus, we can ditch all of the linked list storage code
entirely, making the code much simpler.

The test unfortunately still does not pass because of an
unrelated bug in handle_options.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It is possible to break your repository config by creating an invalid key.  The
config parser in turn chokes on it:

  $ git init
  Initialized empty Git repository in /tmp/gittest/.git/
  $ git config .foo false
  $ git config core.bare
  fatal: bad config file line 6 in .git/config

This patch makes git-config reject keys which start or end with a dot and adds
tests for these cases.
Signed-off-by: NLibor Pechacek <lpechacek@suse.cz>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Sanity-check config variable names when adding and retrieving them.  As a side
effect code duplication between git_config_set_multivar and get_value (in
builtin/config.c) was removed and the common functionality was placed in
git_config_parse_key.

This breaks a test in t1300 which used invalid section-less keys in the tests
for "git -c". However, allowing such names there was useless, since there was
no way to set them via config file, and no part of git actually tried to use
section-less keys. This patch updates the test to use more realistic examples
as well as adding its own test.
Signed-off-by: NLibor Pechacek <lpechacek@suse.cz>
Acked-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The git_config() function signals error by returning -1 in
two instances:

  1. An actual error occurs in opening a config file (parse
     errors cause an immediate die).

  2. Of the three possible config files, none was found.

However, this second case is often not an error at all; it
simply means that the user has no configuration (they are
outside a repo, and they have no ~/.gitconfig file). This
can lead to confusing errors, such as when the bash
completion calls "git config --list" outside of a repo. If
the user has a ~/.gitconfig, the command completes
succesfully; if they do not, it complains to stderr.

This patch allows callers of git_config to distinguish
between the two cases. Error is signaled by -1, and
otherwise the return value is the number of files parsed.
This means that the traditional "git_config(...) < 0" check
for error should work, but callers who want to know whether
we parsed any files or not can still do so.

[jc: with tests from Jonathan]
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

These two tests fail on msysGit because /dev/null is an alias for nul on
Windows and when reading the value back from git config the alias does
not match the real filename. Also the HOME environment variable has a
unix-style path but git returns a native equivalent path for '~'.  As
these are platform-dependent equivalent results it seems simplest to
skip the test entirely.

Moves the NOT_MINGW prereq from t5503 into the test library.
Signed-off-by: NPat Thoyts <patthoyts@users.sourceforge.net>

If $HOME is unset (as in some automated build situations),
currently

	git config --path path.home "~"
	git config --path --get path.home

segfaults.  Error out with

	Failed to expand user dir in: '~/'

instead.
Reported-by: NJulien Cristau <jcristau@debian.org>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The values passed this way will override whatever is defined
in the config files.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When your current directory is not at the root of the working tree, and you
use the "-f" option with a relative path, the current code tries to read
from a wrong file, since argv[2] is now beyond the end of the rearranged
argument list.

This patch replaces the incorrect argv[2] with the variable holding the
given config file name.

The bug was introduced by d64ec16c (git config: reorganize to use parseopt).

[jc: added test]
Signed-off-by: NJohan Herland <johan@herland.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

395de250 (Expand ~ and ~user in core.excludesfile, commit.template)
introduced a C function git_config_pathname, doing ~/ and ~user/
expansion. This patch makes the feature available to scripts with 'git
config --get --path'.
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Configuration values are expected to be quoted when they have leading or
trailing whitespace, but inner whitespace should be kept verbatim even if
the value is not quoted. This is already documented in git-config(1), but
the code caused inner whitespace to be collapsed to a single space,
breaking, for example, clones from a path that has two consecutive spaces
in it, as future fetches would only see a single space.
Reported-by: NJohn te Bokkel <tanj.tanj@gmail.com>
Signed-off-by: NBjörn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NAlex Vandiver <alex@chmrr.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Many tests depend on that symbolic links work.  This introduces a check
that sets the prerequisite tag SYMLINKS if the file system supports
symbolic links.  Since so many tests have to check for this prerequisite,
we do the check in test-lib.sh, so that we don't need to repeat the test
in many scripts.

To check for 'ln -s' failures, you can use a FAT partition on Linux:

$ mkdosfs -C git-on-fat 1000000
$ sudo mount -o loop,uid=j6t,gid=users,shortname=winnt git-on-fat /mnt

Clone git to /mnt and

$ GIT_SKIP_TESTS='t0001.1[34] t0010 t1301 t403[34] t4129.[47] t5701.7
          t7701.3 t9100 t9101.26 t9119 t9124.[67] t9200.10 t9600.6' \
        make test

(These additionally skipped tests depend on POSIX permissions that FAT on
Linux does not provide.)
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>

Option --replace-all only allows at least two arguments, so
documentation was needing to be updated accordingly. A test showing
that the command fails with only one parameter is also provided.
Signed-off-by: NCarlos Rica <jasampler@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some of the tests checked the exit code manually, even going
so far as to run git outside of the test_expect harness.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As the testcase demonstrates, it's possible for split_cmdline to return -1 and
deallocate any memory it's allocated, if the config string is missing an end
quote.  In both the cases below, which are the only calling sites, the return
isn't checked, and using the pointer causes a pretty immediate segfault.
Signed-off-by: NDeskin Miller <deskinm@umich.edu>
Acked-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

This patch changes every occurrence of "! git" -- with the meaning
that a git call has to gracefully fail -- into "test_must_fail git".

This is useful to

 - make sure the test does not fail because of a signal,
   e.g. SIGSEGV, and

 - advertise the use of "test_must_fail" for new tests.
Signed-off-by: NStephan Beyer <s-beyer@gmx.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>