Commit graph

386 commits

Author SHA1 Message Date
Junio C Hamano
149a4211a4 Merge branch 'jc/custom-comment-char'
Allow a configuration variable core.commentchar to customize the
character used to comment out the hint lines in the edited text from
the default '#'.

* jc/custom-comment-char:
  Allow custom "comment char"
2013-02-04 10:23:49 -08:00
Jeff King
1b86bbb0ad config: add helper function for parsing key names
The config callback functions get keys of the general form:

  section.subsection.key

(where the subsection may be contain arbitrary data, or may
be missing). For matching keys without subsections, it is
simple enough to call "strcmp". Matching keys with
subsections is a little more complicated, and each callback
does it in an ad-hoc way, usually involving error-prone
pointer arithmetic.

Let's provide a helper that keeps the pointer arithmetic all
in one place.

Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-23 08:41:49 -08:00
Robin Rosenberg
c08e4d5b5c Enable minimal stat checking
Specifically the fields uid, gid, ctime, ino and dev are set to zero
by JGit. Other implementations, eg. Git in cygwin are allegedly also
somewhat incompatible with Git For Windows and on *nix platforms
the resolution of the timestamps may differ.

Any stat checking by git will then need to check content, which may
be very slow, particularly on Windows. Since mtime and size
is typically enough we should allow the user to tell git to avoid
checking these fields if they are set to zero in the index.

This change introduces a core.checkstat config option where the
the user can select to check all fields (default), or just size
and the whole second part of mtime (minimal).

Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-22 09:33:16 -08:00
Junio C Hamano
eff80a9fd9 Allow custom "comment char"
Some users do want to write a line that begin with a pound sign, #,
in their commit log message.  Many tracking system recognise
a token of #<bugid> form, for example.

The support we offer these use cases is not very friendly to the end
users.  They have a choice between

 - Don't do it.  Avoid such a line by rewrapping or indenting; and

 - Use --cleanup=whitespace but remove all the hint lines we add.

Give them a way to set a custom comment char, e.g.

    $ git -c core.commentchar="%" commit

so that they do not have to do either of the two workarounds.

[jc: although I started the topic, all the tests and documentation
updates, many of the call sites of the new strbuf_add_commented_*()
functions, and the change to git-submodule.sh scripted Porcelain are
from Ralf.]

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-16 12:48:22 -08:00
Junio C Hamano
4f43e9726a Merge branch 'jn/warn-on-inaccessible-loosen'
Deal with a situation where .config/git is a file and we notice
.config/git/config is not readable due to ENOTDIR, not ENOENT.

* jn/warn-on-inaccessible-loosen:
  config: exit on error accessing any config file
  doc: advertise GIT_CONFIG_NOSYSTEM
  config: treat user and xdg config permission problems as errors
  config, gitignore: failure to access with ENOTDIR is ok
2013-01-06 22:11:16 -08:00
Junio C Hamano
29fb151525 Merge branch 'jk/error-const-return'
Help compilers' flow analysis by making it more explicit that
error() always returns -1, to reduce false "variable used
uninitialized" warnings.  Looks somewhat ugly but not too much.

* jk/error-const-return:
  silence some -Wuninitialized false positives
  make error()'s constant return value more visible
2013-01-05 23:42:00 -08:00
Jeff King
a469a10193 silence some -Wuninitialized false positives
There are a few error functions that simply wrap error() and
provide a standardized message text. Like error(), they
always return -1; knowing that can help the compiler silence
some false positive -Wuninitialized warnings.

One strategy would be to just declare these as inline in the
header file so that the compiler can see that they always
return -1. However, gcc does not always inline them (e.g.,
it will not inline opterror, even with -O3), which renders
our change pointless.

Instead, let's follow the same route we did with error() in
the last patch, and define a macro that makes the constant
return value obvious to the compiler.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-15 10:45:59 -08:00
Jeff King
086109006f mailmap: support reading mailmap from blobs
In a bare repository, there isn't a simple way to respect an
in-tree mailmap without extracting it to a temporary file.
This patch provides a config variable, similar to
mailmap.file, which reads the mailmap from a blob in the
repository.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-12 11:12:35 -08:00
Junio C Hamano
2739889c98 Merge branch 'jk/config-ignore-duplicates'
Drop duplicate detection from "git-config --get"; this lets it
better match the internal config callbacks, which clears up some
corner cases with includes.

* jk/config-ignore-duplicates:
  builtin/config.c: Fix a sparse warning
  git-config: use git_config_with_options
  git-config: do not complain about duplicate entries
  git-config: collect values instead of immediately printing
  git-config: fix regexp memory leaks on error conditions
  git-config: remove memory leak of key regexp
  t1300: test "git config --get-all" more thoroughly
  t1300: remove redundant test
  t1300: style updates
2012-11-21 13:16:44 -08:00
Jeff King
97ed50f93b git-config: fix regexp memory leaks on error conditions
The get_value function has a goto label for cleaning up on
errors, but it only cleans up half of what the function
might allocate. Let's also clean up the key and regexp
variables there.

Note that we need to take special care when compiling the
regex fails to clean it up ourselves, since it is in a
half-constructed state (we would want to free it, but not
regfree it).

Similarly, we fix git_config_parse_key to return NULL when
it fails, not a pointer to some already-freed memory.

Signed-off-by: Jeff King <peff@peff.net>
2012-10-24 03:36:54 -04:00
Jonathan Nieder
8f2bbe452e config: exit on error accessing any config file
There is convenience in warning and moving on when somebody has a
bogus permissions on /etc/gitconfig and cannot do anything about it.
But the cost in predictability and security is too high --- when
unreadable config files are skipped, it means an I/O error or
permissions problem causes important configuration to be bypassed.

For example, servers may depend on /etc/gitconfig to enforce security
policy (setting transfer.fsckObjects or receive.deny*).  Best to
always error out when encountering trouble accessing a config file.

This may add inconvenience in some cases:

  1. You are inspecting somebody else's repo, and you do not have
     access to their .git/config file.  Git typically dies in this
     case already since we cannot read core.repositoryFormatVersion,
     so the change should not be too noticeable.

  2. You have used "sudo -u" or a similar tool to switch uid, and your
     environment still points Git at your original user's global
     config, which is not readable.  In this case people really would
     be inconvenienced (they would rather see the harmless warning and
     continue the operation) but they can work around it by setting
     HOME appropriately after switching uids.

  3. You do not have access to /etc/gitconfig due to a broken setup.
     In this case, erroring out is a good way to put pressure on the
     sysadmin to fix the setup.  While they wait for a reply, users
     can set GIT_CONFIG_NOSYSTEM to true to keep Git working without
     complaint.

After this patch, errors accessing the repository-local and systemwide
config files and files requested in include directives cause Git to
exit, just like errors accessing ~/.gitconfig.

Explained-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-14 10:14:52 -07:00
Jonathan Nieder
96b9e0e313 config: treat user and xdg config permission problems as errors
Git reads multiple configuration files: settings come first from the
system config file (typically /etc/gitconfig), then the xdg config
file (typically ~/.config/git/config), then the user's dotfile
(~/.gitconfig), then the repository configuration (.git/config).

Git has always used access(2) to decide whether to use each file; as
an unfortunate side effect, that means that if one of these files is
unreadable (e.g., EPERM or EIO), git skips it.  So if I use
~/.gitconfig to override some settings but make a mistake and give it
the wrong permissions then I am subject to the settings the sysadmin
chose for /etc/gitconfig.

Better to error out and ask the user to correct the problem.

This only affects the user and xdg config files, since the user
presumably has enough access to fix their permissions.  If the system
config file is unreadable, the best we can do is to warn about it so
the user knows to notify someone and get on with work in the meantime.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-13 21:59:16 -07:00
Ben Walton
0971e992c4 Remove the hard coded length limit on variable names in config files
Previously while reading the variable names in config files, there
was a 256 character limit with at most 128 of those characters being
used by the section header portion of the variable name.  This
limitation was only enforced while reading the config files.  It was
possible to write a config file that was not subsequently readable.

Instead of enforcing this limitation for both reading and writing,
remove it entirely by changing the var member of the config_file
struct to a strbuf instead of a fixed length buffer.  Update all of
the parsing functions in config.c to use the strbuf instead of the
static buffer.

The parsing functions that returned the base length of the variable
name now return simply 0 for success and -1 for failure.  The base
length information is obtained through the strbuf's len member.

We now send the buf member of the strbuf to external callback
functions to preserve the external api.  None of the external
callers rely on the old size limitation for sizing their own buffers
so removing the limit should have no externally visible effect.

Signed-off-by: Ben Walton <bdwalton@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-01 12:27:45 -07:00
Jeff King
ba8bd8300a config: warn on inaccessible files
Before reading a config file, we check "!access(path, R_OK)"
to make sure that the file exists and is readable. If it's
not, then we silently ignore it.

For the case of ENOENT, this is fine, as the presence of the
file is optional. For other cases, though, it may indicate a
configuration error (e.g., not having permissions to read
the file). Let's print a warning in these cases to let the
user know.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-21 14:46:11 -07:00
Junio C Hamano
a3ad9a0f8d Merge branch 'mm/config-xdg'
* mm/config-xdg:
  config: fix several access(NULL) calls
2012-07-22 12:56:27 -07:00
Matthieu Moy
e3ebc35b16 config: fix several access(NULL) calls
When $HOME is unset, home_config_paths fails and returns NULL pointers
for user_config and xdg_config. Valgrind complains with Syscall param
access(pathname) points to unaddressable byte(s).

Don't call blindly access() on these variables, but test them for
NULL-ness before.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-16 09:59:06 -07:00
Junio C Hamano
b856ad623e Merge branch 'tb/sanitize-decomposed-utf-8-pathname'
Teaches git to normalize pathnames read from readdir(3) and all
arguments from the command line into precomposed UTF-8 (assuming
that they come as decomposed UTF-8) to work around issues on Mac OS.

I think there still are other places that need conversion
(e.g. paths that are read from stdin for some commands), but this
should be a good first step in the right direction.

* tb/sanitize-decomposed-utf-8-pathname:
  git on Mac OS and precomposed unicode
2012-07-13 15:37:51 -07:00
Torsten Bögershausen
76759c7dff git on Mac OS and precomposed unicode
Mac OS X mangles file names containing unicode on file systems HFS+,
VFAT or SAMBA.  When a file using unicode code points outside ASCII
is created on a HFS+ drive, the file name is converted into
decomposed unicode and written to disk. No conversion is done if
the file name is already decomposed unicode.

Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same
result as open("\x41\xcc\x88",...) with a decomposed "Ä".

As a consequence, readdir() returns the file names in decomposed
unicode, even if the user expects precomposed unicode.  Unlike on
HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in
precomposed unicode, but readdir() still returns file names in
decomposed unicode.  When a git repository is stored on a network
share using SAMBA, file names are send over the wire and written to
disk on the remote system in precomposed unicode, but Mac OS X
readdir() returns decomposed unicode to be compatible with its
behaviour on HFS+ and VFAT.

The unicode decomposition causes many problems:

- The names "git add" and other commands get from the end user may
  often be precomposed form (the decomposed form is not easily input
  from the keyboard), but when the commands read from the filesystem
  to see what it is going to update the index with already is on the
  filesystem, readdir() will give decomposed form, which is different.

- Similarly "git log", "git mv" and all other commands that need to
  compare pathnames found on the command line (often but not always
  precomposed form; a command line input resulting from globbing may
  be in decomposed) with pathnames found in the tree objects (should
  be precomposed form to be compatible with other systems and for
  consistency in general).

- The same for names stored in the index, which should be
  precomposed, that may need to be compared with the names read from
  readdir().

NFS mounted from Linux is fully transparent and does not suffer from
the above.

As Mac OS X treats precomposed and decomposed file names as equal,
we can

 - wrap readdir() on Mac OS X to return the precomposed form, and

 - normalize decomposed form given from the command line also to the
   precomposed form,

to ensure that all pathnames used in Git are always in the
precomposed form.  This behaviour can be requested by setting
"core.precomposedunicode" configuration variable to true.

The code in compat/precomposed_utf8.c implements basically 4 new
functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() and precompose_argv().  The first three
are to wrap opendir(3), readdir(3), and closedir(3) functions.

The argv[] conversion allows to use the TAB filename completion done
by the shell on command line.  It tolerates other tools which use
readdir() to feed decomposed file names into git.

When creating a new git repository with "git init" or "git clone",
"core.precomposedunicode" will be set "false".

The user needs to activate this feature manually.  She typically
sets core.precomposedunicode to "true" on HFS and VFAT, or file
systems mounted via SAMBA.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-08 22:03:46 -07:00
Huynh Khoi Nguyen Nguyen
21cf322791 config: read (but not write) from $XDG_CONFIG_HOME/git/config file
Teach git to read the "gitconfig" information from a new location,
$XDG_CONFIG_HOME/git/config; this allows the user to avoid
cluttering $HOME with many per-application configuration files.

In the order of reading, this file comes between the global
configuration file (typically $HOME/.gitconfig) and the system wide
configuration file (typically /etc/gitconfig).

We do not write to this new location (yet).

If $XDG_CONFIG_HOME is either not set or empty, $HOME/.config/git/config
will be used. This is in line with XDG specification.

If the new file does not exist, the behavior is unchanged.

Signed-off-by: Huynh Khoi Nguyen Nguyen <Huynh-Khoi-Nguyen.Nguyen@ensimag.imag.fr>
Signed-off-by: Valentin Duperray <Valentin.Duperray@ensimag.imag.fr>
Signed-off-by: Franck Jonas <Franck.Jonas@ensimag.imag.fr>
Signed-off-by: Lucien Kong <Lucien.Kong@ensimag.imag.fr>
Signed-off-by: Thomas Nguy <Thomas.Nguy@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-25 09:05:55 -07:00
Jeff King
9597921b6c move identity config parsing to ident.c
There's no reason for this to be in config, except that once
upon a time all of the config parsing was there. It makes
more sense to keep the ident code together.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-22 09:07:53 -07:00
Junio C Hamano
a3db8511b7 Merge branch 'mm/simple-push'
New users tend to work on one branch at a time and push the result
out. The current and upstream modes of push is a more suitable default
mode than matching mode for these people, but neither is surprise-free
depending on how the project is set up. Introduce a "simple" mode that
is a subset of "upstream" but only works when the branch is named the same
between the remote and local repositories.

The plan is to make it the new default when push.default is not
configured.

By Matthieu Moy (5) and others
* mm/simple-push:
  push.default doc: explain simple after upstream
  push: document the future default change for push.default (matching -> simple)
  t5570: use explicit push refspec
  push: introduce new push.default mode "simple"
  t5528-push-default.sh: add helper functions
  Undocument deprecated alias 'push.default=tracking'
  Documentation: explain push.default option a bit more
2012-05-02 13:51:24 -07:00
Junio C Hamano
563b3527b4 Merge branch 'jk/maint-config-bogus-section'
"git config --rename-section" to rename an existing section into a
bogus one did not check the new name.

By Jeff King
* jk/maint-config-bogus-section:
  config: reject bogus section names for --rename-section
2012-04-30 14:46:46 -07:00
Jeff King
4c0a89fcde config: expand tildes in include.path variable
You can already use relative paths in include.path, which
means that including "foo" from your global "~/.gitconfig"
will look in your home directory. However, you might want to
do something clever like putting "~/.gitconfig-foo" in a
specific repository's config file.

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-29 17:46:32 -07:00
Jeff King
94a35b1aea config: reject bogus section names for --rename-section
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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-25 21:19:06 -07:00
Matthieu Moy
b55e677522 push: introduce new push.default mode "simple"
When calling "git push" without argument, we want to allow Git to do
something simple to explain and safe. push.default=matching is unsafe
when used to push to shared repositories, and hard to explain to
beginners in some contexts. It is debatable whether 'upstream' or
'current' is the safest or the easiest to explain, so introduce a new
mode called 'simple' that is the intersection of them: push to the
upstream branch, but only if it has the same name remotely. If not, give
an error that suggests the right command to push explicitely to
'upstream' or 'current'.

A question is whether to allow pushing when no upstream is configured. An
argument in favor of allowing the push is that it makes the new mode work
in more cases. On the other hand, refusing to push when no upstream is
configured encourages the user to set the upstream, which will be
beneficial on the next pull. Lacking better argument, we chose to deny
the push, because it will be easier to change in the future if someone
shows us wrong.

Original-patch-by: Jeff King <peff@peff.net>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-24 15:22:16 -07:00
Junio C Hamano
3f263099fc Merge branch 'ms/maint-config-error-at-eol-linecount'
When "git config" diagnoses an error in a configuration file and
shows the line number for the offending line, it miscounted if the
error was at the end of line.

By Martin Stenberg
* ms/maint-config-error-at-eol-linecount:
  config: report errors at the EOL with correct line number

Conflicts:
	t/t1300-repo-config.sh
2012-03-13 12:35:53 -07:00
Martin Stenberg
4b34059355 config: report errors at the EOL with correct line number
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: Martin Stenberg <martin@gnutiken.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-12 09:39:06 -07:00
Jeff King
9b25a0b52e config: add include directive
It can be useful to split your ~/.gitconfig across multiple
files. For example, you might have a "main" file which is
used on many machines, but a small set of per-machine
tweaks. Or you may want to make some of your config public
(e.g., clever aliases) while keeping other data back (e.g.,
your name or other identifying information). Or you may want
to include a number of config options in some subset of your
repos without copying and pasting (e.g., you want to
reference them from the .git/config of participating repos).

This patch introduces an include directive for config files.
It looks like:

  [include]
    path = /path/to/file

This is syntactically backwards-compatible with existing git
config parsers (i.e., they will see it as another config
entry and ignore it unless you are looking up include.path).

The implementation provides a "git_config_include" callback
which wraps regular config callbacks. Callers can pass it to
git_config_from_file, and it will transparently follow any
include directives, passing all of the discovered options to
the real callback.

Include directives are turned on automatically for "regular"
git config parsing. This includes calls to git_config, as
well as calls to the "git config" program that do not
specify a single file (e.g., using "-f", "--global", etc).
They are not turned on in other cases, including:

  1. Parsing of other config-like files, like .gitmodules.
     There isn't a real need, and I'd rather be conservative
     and avoid unnecessary incompatibility or confusion.

  2. Reading single files via "git config". This is for two
     reasons:

       a. backwards compatibility with scripts looking at
          config-like files.

       b. inspection of a specific file probably means you
	  care about just what's in that file, not a general
          lookup for "do we have this value anywhere at
	  all". If that is not the case, the caller can
	  always specify "--includes".

  3. Writing files via "git config"; we want to treat
     include.* variables as literal items to be copied (or
     modified), and not expand them. So "git config
     --unset-all foo.bar" would operate _only_ on
     .git/config, not any of its included files (just as it
     also does not operate on ~/.gitconfig).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17 07:59:55 -08:00
Jeff King
4a7bb5ba95 config: eliminate config_exclusive_filename
This is a magic global variable that was intended as an
override to the usual git-config lookup process. Once upon a
time, you could specify GIT_CONFIG to any git program, and
it would look only at that file. This turned out to be
confusing and cause a lot of bugs for little gain. As a
result, dc87183 (Only use GIT_CONFIG in "git config", not
other programs, 2008-06-30) took this away for all callers
except git-config.

Since git-config no longer uses it either, the variable can
just go away. As the diff shows, nobody was setting to
anything except NULL, so we can just replace any sites where
it was read with NULL.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17 07:58:54 -08:00
Jeff King
c9b5e2a57d config: provide a version of git_config with more options
Callers may want to provide a specific version of a file in which to look
for config. Right now this can be done by setting the magic global
config_exclusive_filename variable.  By providing a version of git_config
that takes a filename, we can take a step towards making this magic global
go away.

Furthermore, by providing a more "advanced" interface, we now have a a
natural place to add new options for callers like git-config, which care
about tweaking the specifics of config lookup, without disturbing the
large number of "simple" users (i.e., every other part of git).

The astute reader of this patch may notice that the logic for handling
config_exclusive_filename was taken out of git_config_early, but added
into git_config. This means that git_config_early will no longer respect
config_exclusive_filename.  That's OK, because the only other caller of
git_config_early is check_repository_format_gently, but the only function
which sets config_exclusive_filename is cmd_config, which does not call
check_repository_format_gently (and if it did, it would have been a bug,
anyway, as we would be checking the repository format in the wrong file).

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17 07:58:07 -08:00
Jeff King
42bd39b57f config: teach git_config_rename_section a file argument
The other config-writing functions (git_config_set and
git_config_set_multivar) each have an -"in_file" version to
write a specific file. Let's add one for rename_section,
with the eventual goal of moving away from the magic
config_exclusive_filename global.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17 07:52:41 -08:00
Jeff King
0a5f575927 config: teach git_config_set_multivar_in_file a default path
The git_config_set_multivar_in_file function takes a
filename argument to specify the file into which the values
should be written. Currently, this value must be non-NULL.
Callers which want to write to the default location must use
the regular, non-"in_file" version, which will either write
to config_exclusive_filename, or to the repo config if the
exclusive filename is NULL.

Let's migrate the "default to using repo config" logic into
the "in_file" form. That will let callers get the same
default-if-NULL behavior as one gets with
config_exclusive_filename, but without having to use the
global variable.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17 07:52:41 -08:00
Junio C Hamano
48b303675a Merge branch 'jc/stream-to-pack'
* jc/stream-to-pack:
  bulk-checkin: replace fast-import based implementation
  csum-file: introduce sha1file_checkpoint
  finish_tmp_packfile(): a helper function
  create_tmp_packfile(): a helper function
  write_pack_header(): a helper function

Conflicts:
	pack.h
2011-12-16 22:33:40 -08:00
Junio C Hamano
5d6c53bb23 Merge branch 'na/strtoimax'
* na/strtoimax:
  Support sizes >=2G in various config options accepting 'g' sizes.
  Compatibility: declare strtoimax() under NO_STRTOUMAX
  Add strtoimax() compatibility function.
2011-12-05 15:12:49 -08:00
Junio C Hamano
568508e765 bulk-checkin: replace fast-import based implementation
This extends the earlier approach to stream a large file directly from the
filesystem to its own packfile, and allows "git add" to send large files
directly into a single pack. Older code used to spawn fast-import, but the
new bulk-checkin API replaces it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-12-01 11:46:09 -08:00
Ramsay Jones
05bab3ea28 config.c: Fix a static buffer overwrite bug by avoiding mkpath()
On cygwin, test number 21 of t3200-branch.sh (git branch -m q q2
without config should succeed) fails. The failure involves the
functions from path.c which parcel out internal static buffers
from the git_path() and mkpath() functions.

In particular, the rename_ref() function calls safe_create_leading\
_directories() with a filename returned by git_path("logs/%s", ref).
safe_create_leading_directories(), in turn, calls stat() on each
element of the path it is given. On cygwin, this leads to a call
to git_config() for each component of the path, since this test
explicitly removes the config file. git_config() calls mkpath(), so
on the fourth component of the path, the original buffer passed
into the function is overwritten with the config filename.

Note that this bug is specific to cygwin and it's schizophrenic
stat() functions (see commits adbc0b6, 7faee6b and 7974843). The
lack of a config file and a path with at least four elements is
also important to trigger the bug.

In order to fix the problem, we replace the call to mkpath() with
a call to mksnpath() and provide our own buffer.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-20 19:32:09 -08:00
Nick Alcock
ebaa1bd407 Support sizes >=2G in various config options accepting 'g' sizes.
The config options core.packedGitWindowSize, core.packedGitLimit,
core.deltaBaseCacheLimit, core.bigFileThreshold, pack.windowMemory and
pack.packSizeLimit all claim to support suffixes up to and including
'g'.  This implies that they should accept sizes >=2G on 64-bit
systems: certainly, specifying a size of 3g should not silently be
translated to zero or transformed into a large negative value due to
integer overflow.  However, due to use of git_config_int() rather than
git_config_ulong(), that is exactly what happens:

% git config core.bigFileThreshold 2g
% git gc --aggressive # with extra debugging code to print out
                      # core.bigfilethreshold after parsing
bigfilethreshold: -2147483648
[...]

This is probably irrelevant for core.deltaBaseCacheLimit, but is
problematic for the other values.  (It is particularly problematic for
core.packedGitLimit, which can't even be set to its default value in
the config file due to this bug.)

This fixes things for 32-bit platforms as well.  They get the usual bad
config error if an overlarge value is specified, e.g.:

fatal: bad config value for 'core.bigfilethreshold' in /home/nix/.gitconfig

This is detected in all cases, even if the 32-bit platform has no size
larger than 'long'.  For signed integral configuration values, we also
detect the case where the value is too large for the signed type but
not the unsigned type.

Signed-off-by: Nick Alcock <nix@esperi.org.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-11-05 23:10:43 -07:00
Junio C Hamano
a200dc8e62 Merge branch 'bc/attr-ignore-case'
* bc/attr-ignore-case:
  attr.c: respect core.ignorecase when matching attribute patterns
  attr: read core.attributesfile from git_default_core_config
  builtin/mv.c: plug miniscule memory leak
  cleanup: use internal memory allocation wrapper functions everywhere
  attr.c: avoid inappropriate access to strbuf "buf" member

Conflicts:
	transport-helper.c
2011-10-17 21:37:14 -07:00
Junio C Hamano
64589a03a8 attr: read core.attributesfile from git_default_core_config
This code calls git_config from a helper function to parse the config entry
it is interested in.  Calling git_config in this way may cause a problem if
the helper function can be called after a previous call to git_config by
another function since the second call to git_config may reset some
variable to the value in the config file which was previously overridden.

The above is not a problem in this case since the function passed to
git_config only parses one config entry and the variable it sets is not
assigned outside of the parsing function.  But a programmer who desires
all of the standard config options to be parsed may be tempted to modify
git_attr_config() so that it falls back to git_default_config() and then it
_would_ be vulnerable to the above described behavior.

So, move the call to git_config up into the top-level cmd_* function and
move the responsibility for parsing core.attributesfile into the main
config file parser.

Which is only the logical thing to do ;-)

Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-06 13:54:32 -07:00
Junio C Hamano
cd4093b603 Merge branch 'rr/revert-cherry-pick-continue'
* rr/revert-cherry-pick-continue:
  builtin/revert.c: make commit_list_append() static
  revert: Propagate errors upwards from do_pick_commit
  revert: Introduce --continue to continue the operation
  revert: Don't implicitly stomp pending sequencer operation
  revert: Remove sequencer state when no commits are pending
  reset: Make reset remove the sequencer state
  revert: Introduce --reset to remove sequencer state
  revert: Make pick_commits functionally act on a commit list
  revert: Save command-line options for continuing operation
  revert: Save data for continuing after conflict resolution
  revert: Don't create invalid replay_opts in parse_args
  revert: Separate cmdline parsing from functional code
  revert: Introduce struct to keep command-line options
  revert: Eliminate global "commit" variable
  revert: Rename no_replay to record_origin
  revert: Don't check lone argument in get_encoding
  revert: Simplify and inline add_message_to_msg
  config: Introduce functions to write non-standard file
  advice: Introduce error_resolve_conflict
2011-10-05 12:36:19 -07:00
Junio C Hamano
96790ca029 Merge branch 'jc/pack-order-tweak'
* jc/pack-order-tweak:
  pack-objects: optimize "recency order"
  core: log offset pack data accesses happened
2011-08-05 14:54:57 -07:00
Ramkumar Ramachandra
5ec3118293 config: Introduce functions to write non-standard file
Introduce two new functions corresponding to "git_config_set" and
"git_config_set_multivar" to write a non-standard configuration file.
Expose these new functions in cache.h for other git programs to use.

Helped-by: Jeff King <peff@peff.net>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04 15:40:41 -07:00
Junio C Hamano
ed16d0dbf1 Merge branch 'maint'
* maint:
  doc/fast-import: clarify notemodify command
  Documentation: minor grammatical fix in rev-list-options.txt
  Documentation: git-filter-branch honors replacement refs
  remote-curl: Add a format check to parsing of info/refs
  git-config: Remove extra whitespaces
2011-07-22 13:58:46 -07:00
Pavan Kumar Sunkara
8b5900751a git-config: Remove extra whitespaces
Remove extra whitespaces introduced by commits
01ebb9dc and fc1905bb

Signed-off-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-19 13:43:34 -07:00
Junio C Hamano
ff94409da9 Merge branch 'jk/clone-cmdline-config'
* jk/clone-cmdline-config:
  clone: accept config options on the command line
  config: make git_config_parse_parameter a public function
  remote: use new OPT_STRING_LIST
  parse-options: add OPT_STRING_LIST helper
2011-07-19 09:45:24 -07:00
Junio C Hamano
fe01ef31b7 Merge branch 'jk/maint-config-param'
* jk/maint-config-param:
  config: use strbuf_split_str instead of a temporary strbuf
  strbuf: allow strbuf_split to work on non-strbufs
  config: avoid segfault when parsing command-line config
  config: die on error in command-line config
  fix "git -c" parsing of values with equals signs
  strbuf_split: add a max parameter
2011-07-19 09:45:21 -07:00
Junio C Hamano
5f44324d88 core: log offset pack data accesses happened
In a workload other than "git log" (without pathspec nor any option that
causes us to inspect trees and blobs), the recency pack order is said to
cause the access jump around quite a bit. Add a hook to allow us observe
how bad it is.

"git config core.logpackaccess /var/tmp/pal.txt" will give you the log
in the specified file.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-07-06 19:09:29 -07:00
Jeff King
2496844bb2 config: make git_config_parse_parameter a public function
We use this internally to parse "git -c core.foo=bar", but
the general format of "key=value" is useful for other
places.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22 11:25:21 -07:00
Jeff King
f77bccaeba config: use strbuf_split_str instead of a temporary strbuf
This saves an allocation and copy, and also fixes a minor
memory leak.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22 11:24:51 -07:00
Jeff King
c5d6350bdc config: avoid segfault when parsing command-line config
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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22 11:24:51 -07:00
Jeff King
1c2c9bee1b config: die on error in command-line config
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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22 11:24:50 -07:00
Jeff King
5bf6529aaa fix "git -c" parsing of values with equals signs
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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-22 11:24:50 -07:00
Ramsay Jones
924aaf3ef7 config.c: Make git_config() work correctly when called recursively
On Cygwin, this fixes a test failure in t3301-notes.sh (test 98,
"git notes copy --for-rewrite (disabled)").

The test failure is caused by a recursive call to git_config() which
has the effect of skipping to the end-of-file while processing the
"notes.rewriteref" config variable. Thus, any config variables that
appear after "notes.rewriteref" are simply ignored by git_config().
Also, we note that the original FILE handle is leaked as a result
of the recursive call.

The recursive call to git_config() is due to the "schizophrenic stat"
functions on cygwin, where one of two different implementations of
the l/stat functions is selected lazily, depending on some config
variables.

In this case, the init_copy_notes_for_rewrite() function calls
git_config() with the notes_rewrite_config() callback function.
This callback, while processing the "notes.rewriteref" variable,
in turn calls string_list_add_refs_by_glob() to process the
associated ref value. This eventually leads to a call to the
get_ref_dir() function, which in turn calls stat(). On cygwin,
the stat() macro leads to an indirect call to cygwin_stat_stub()
which, via init_stat(), then calls git_config() in order to
determine which l/stat implementation to bind to.

In order to solve this problem, we modify git_config() so that the
global state variables used by the config reading code is packaged
up and managed on a local state stack.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-06-16 15:10:59 -07:00
Junio C Hamano
1c6e3514d0 Merge branch 'jk/maint-config-alias-fix' into maint
* jk/maint-config-alias-fix:
  handle_options(): do not miscount how many arguments were used
  config: always parse GIT_CONFIG_PARAMETERS during git_config
  git_config: don't peek at global config_parameters
  config: make environment parsing routines static
2011-06-01 14:05:22 -07:00
Ramsay Jones
766d6268c6 config.c: Remove unused git_config_global() function
Commit 8f323c00 (drop support for GIT_CONFIG_NOGLOBAL, 15-03-2011)
removed the git_config_global() function, among other things, since
it is no longer required. Unfortunately, this function has since
been unintentionally restored by a faulty conflict resolution.

Remove it.

Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-31 10:51:18 -07:00
Junio C Hamano
1f9a980636 Merge branch 'jk/maint-config-alias-fix'
* jk/maint-config-alias-fix:
  handle_options(): do not miscount how many arguments were used
  config: always parse GIT_CONFIG_PARAMETERS during git_config
  git_config: don't peek at global config_parameters
  config: make environment parsing routines static

Conflicts:
	config.c
2011-05-30 20:19:14 -07:00
Jeff King
06eb708f33 config: always parse GIT_CONFIG_PARAMETERS during git_config
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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24 16:25:36 -07:00
Jeff King
5a0c9eeb89 git_config: don't peek at global config_parameters
The config_parameters list in config.c is an implementation
detail of git_config_from_parameters; instead, that function
should tell us whether it found anything.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24 16:20:56 -07:00
Jeff King
3ddf0968c2 config: make environment parsing routines static
Nobody outside of git_config_from_parameters should need
to use the GIT_CONFIG_PARAMETERS parsing functions, so let's
make them private.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24 16:20:48 -07:00
Michael J Gruber
7a39741999 config: define and document exit codes
The return codes of git_config_set() and friends are magic numbers right
in the source. #define them in cache.h where the functions are declared,
and use the constants in the source.

Also, mention the resulting exit codes of "git config" in its man page
(and complete the list).

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-17 21:01:17 -07:00
Junio C Hamano
ec70f52f6f convert: rename the "eol" global variable to "core_eol"
Yes, it is clear that "eol" wants to mean some sort of end-of-line thing,
but as the name of a global variable, it is way too short to describe what
kind of end-of-line thing it wants to represent. Besides, there are many
codepaths that want to use their own local "char *eol" variable to point
at the end of the current line they are processing.

This global variable holds what we read from core.eol configuration
variable. Name it as such.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-09 14:58:52 -07:00
Junio C Hamano
f28d2e33c6 Merge branch 'jc/pack-objects-bigfile' into maint
* jc/pack-objects-bigfile:
  Teach core.bigfilethreashold to pack-objects
2011-05-04 14:57:38 -07:00
Junio C Hamano
c5a5f12e5a Merge branch 'ef/maint-strbuf-init'
* ef/maint-strbuf-init:
  config: support values longer than 1023 bytes
  strbuf: make sure buffer is zero-terminated
2011-04-27 11:36:43 -07:00
Junio C Hamano
9cedd16c62 Merge branch 'jc/pack-objects-bigfile'
* jc/pack-objects-bigfile:
  Teach core.bigfilethreashold to pack-objects
2011-04-27 11:36:41 -07:00
Erik Faye-Lund
e96c19c50f config: support values longer than 1023 bytes
parse_value in config.c has a static buffer of 1024 bytes that it
parse the value into. This can sometimes be a problem when a
config file contains very long values.

It's particularly amusing that git-config already is able to write
such files, so it should probably be able to read them as well.

Fix this by using a strbuf instead of a fixed-size buffer.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-11 14:10:06 -07:00
Junio C Hamano
15366280c2 Teach core.bigfilethreashold to pack-objects
The pack-objects command should take notice of the object file and
refrain from attempting to delta large ones, to be consistent with
the fast-import command.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-05 20:25:49 -07:00
Junio C Hamano
da2584243e Merge branch 'lt/default-abbrev'
* lt/default-abbrev:
  Rename core.abbrevlength back to core.abbrev
  Make the default abbrev length configurable
2011-03-23 14:55:40 -07:00
Junio C Hamano
50aaeca008 Merge branch 'jn/test-sanitize-git-env'
* jn/test-sanitize-git-env:
  tests: scrub environment of GIT_* variables
  config: drop support for GIT_CONFIG_NOGLOBAL
  gitattributes: drop support for GIT_ATTR_NOGLOBAL
  tests: suppress system gitattributes
  tests: stop worrying about obsolete environment variables
2011-03-22 21:38:12 -07:00
Junio C Hamano
a71f09fe3e Rename core.abbrevlength back to core.abbrev
It corresponds to --abbrev=$n command line option after all.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-20 22:26:24 -07:00
Junio C Hamano
b2f6eab402 Merge branch 'maint'
* maint:
  Prepare draft release notes to 1.7.4.2
  gitweb: highlight: replace tabs with spaces
  make_absolute_path: return the input path if it points to our buffer
  valgrind: ignore SSE-based strlen invalid reads
  diff --submodule: split into bite-sized pieces
  cherry: split off function to print output lines
  branch: split off function that writes tracking info and commit subject
  standardize brace placement in struct definitions
  compat: make gcc bswap an inline function
  enums: omit trailing comma for portability

Conflicts:
	RelNotes
2011-03-16 16:59:30 -07:00
Junio C Hamano
61a6f1faec Merge branch 'jh/push-default-upstream-configname' into maint
* jh/push-default-upstream-configname:
  push.default: Rename 'tracking' to 'upstream'
2011-03-16 16:47:26 -07:00
Jonathan Nieder
9cba13ca5d standardize brace placement in struct definitions
In a struct definitions, unlike functions, the prevailing style is for
the opening brace to go on the same line as the struct name, like so:

 struct foo {
	int bar;
	char *baz;
 };

Indeed, grepping for 'struct [a-z_]* {$' yields about 5 times as many
matches as 'struct [a-z_]*$'.

Linus sayeth:

 Heretic people all over the world have claimed that this inconsistency
 is ...  well ...  inconsistent, but all right-thinking people know that
 (a) K&R are _right_ and (b) K&R are right.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-16 12:49:02 -07:00
Jonathan Nieder
8f323c00dd config: drop support for GIT_CONFIG_NOGLOBAL
Now that test-lib sets $HOME to protect against pollution from user
settings, GIT_CONFIG_NOGLOBAL is not needed for use by the test
suite any more.  And as luck would have it, a quick code search
reveals no other users in the wild.

This patch does not affect GIT_CONFIG_NOSYSTEM, which is still
needed.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-15 12:23:30 -07:00
Linus Torvalds
dce9648916 Make the default abbrev length configurable
The default of 7 comes from fairly early in git development, when
seven hex digits was a lot (it covers about 250+ million hash
values). Back then I thought that 65k revisions was a lot (it was what
we were about to hit in BK), and each revision tends to be about 5-10
new objects or so, so a million objects was a big number.

These days, the kernel isn't even the largest git project, and even
the kernel has about 220k revisions (_much_ bigger than the BK tree
ever was) and we are approaching two million objects. At that point,
seven hex digits is still unique for a lot of them, but when we're
talking about just two orders of magnitude difference between number
of objects and the hash size, there _will_ be collisions in truncated
hash values. It's no longer even close to unrealistic - it happens all
the time.

We should both increase the default abbrev that was unrealistically
small, _and_ add a way for people to set their own default per-project
in the git config file.

This is the first step to first make it configurable; the default of 7
is not raised yet.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11 14:42:54 -08:00
Junio C Hamano
adfe4e1ff2 Merge branch 'maint'
* maint:
  Revert "core.abbrevguard: Ensure short object names stay unique a bit longer"
2011-03-10 22:45:49 -08:00
Junio C Hamano
ea2c69ed47 Revert "core.abbrevguard: Ensure short object names stay unique a bit longer"
This reverts commit 72a5b561fc, as adding
fixed number of hexdigits more than necessary to make one object name
locally unique does not help in futureproofing the uniqueness of names
we generate today.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10 22:41:14 -08:00
Junio C Hamano
8978166e53 Merge branch 'jh/push-default-upstream-configname'
* jh/push-default-upstream-configname:
  push.default: Rename 'tracking' to 'upstream'
2011-02-27 21:58:31 -08:00
Libor Pechacek
2169ddc056 Disallow empty section and variable names
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: Libor Pechacek <lpechacek@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-22 15:19:46 -08:00
Libor Pechacek
b09c53a3e3 Sanity-check config variable names
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: Libor Pechacek <lpechacek@suse.cz>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-22 15:19:45 -08:00
Johan Herland
53c403116a push.default: Rename 'tracking' to 'upstream'
Users are sometimes confused with two different types of "tracking" behavior
in Git: "remote-tracking" branches (e.g. refs/remotes/*/*) versus the
merge/rebase relationship between a local branch and its @{upstream}
(controlled by branch.foo.remote and branch.foo.merge config settings).

When the push.default is set to 'tracking', it specifies that a branch should
be pushed to its @{upstream} branch. In other words, setting push.default to
'tracking' applies only to the latter of the above two types of "tracking"
behavior.

In order to make this more understandable to the user, we rename the
push.default == 'tracking' option to push.default == 'upstream'.

push.default == 'tracking' is left as a deprecated synonym for 'upstream'.

Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-16 10:21:52 -08:00
Junio C Hamano
f3bb8b4b84 Merge branch 'nd/setup'
* nd/setup: (47 commits)
  setup_work_tree: adjust relative $GIT_WORK_TREE after moving cwd
  git.txt: correct where --work-tree path is relative to
  Revert "Documentation: always respect core.worktree if set"
  t0001: test git init when run via an alias
  Remove all logic from get_git_work_tree()
  setup: rework setup_explicit_git_dir()
  setup: clean up setup_discovered_git_dir()
  t1020-subdirectory: test alias expansion in a subdirectory
  setup: clean up setup_bare_git_dir()
  setup: limit get_git_work_tree()'s to explicit setup case only
  Use git_config_early() instead of git_config() during repo setup
  Add git_config_early()
  git-rev-parse.txt: clarify --git-dir
  t1510: setup case #31
  t1510: setup case #30
  t1510: setup case #29
  t1510: setup case #28
  t1510: setup case #27
  t1510: setup case #26
  t1510: setup case #25
  ...
2010-12-28 11:26:55 -08:00
Nguyễn Thái Ngọc Duy
dbdf5854b2 Add git_config_early()
This version of git_config() will be used during repository setup.
As a repository is being set up, $GIT_DIR is not nailed down yet,
git_pathdup() should not be used to get $GIT_DIR/config.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-22 14:34:24 -08:00
Junio C Hamano
f7d07cce82 Merge branch 'jk/maint-decorate-01-bool'
* jk/maint-decorate-01-bool:
  handle arbitrary ints in git_config_maybe_bool
2010-12-21 14:30:43 -08:00
Jeff King
db6195efab handle arbitrary ints in git_config_maybe_bool
This function recently gained the ability to recognize the documented "0"
and "1" values as false/true. However, unlike regular git_config_bool, it
did not treat arbitrary non-zero numbers as true.

While this is undocumented and probably ridiculous for somebody to rely
on, it is safer to behave exactly as git_config_bool would. Because
git_config_maybe_bool can be used to retrofit new non-bool values onto
existing bool options, not behaving in exactly the same way is technically
a regression.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-19 10:46:08 -08:00
Junio C Hamano
5e826019ef Merge branch 'jk/maint-decorate-01-bool'
* jk/maint-decorate-01-bool:
  log.decorate: accept 0/1 bool values
2010-12-08 11:24:14 -08:00
Junio C Hamano
63ae595c6d Merge branch 'jc/abbrev-guard'
* jc/abbrev-guard:
  core.abbrevguard: Ensure short object names stay unique a bit longer
2010-12-03 16:10:35 -08:00
Jeff King
b2be2f6aea log.decorate: accept 0/1 bool values
We explicitly document "0" and "1" as synonyms for "false"
and "true" in boolean config options. However, we don't
actually handle those values in git_config_maybe_bool.

In most cases this works fine, as we call git_config_bool,
which in turn calls git_config_bool_or_int, which in turn
calls git_config_maybe_bool. Values of 0/1 are considered
"not bool", but their integer values end up being converted
to the corresponding boolean values.

However, the log.decorate code looks for maybe_bool
explicitly, so that it can fall back to the "short" and
"full" strings. It does not handle 0/1 at all, and considers
them invalid values.

We cannot simply add 0/1 support to git_config_maybe_bool.
That would confuse git_config_bool_or_int, which may want to
distinguish the integer values "0" and "1" from bools.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-17 10:59:23 -08:00
Junio C Hamano
72a5b561fc core.abbrevguard: Ensure short object names stay unique a bit longer
Even though git makes sure that it uses enough hexdigits to show an
abbreviated object name unambiguously, as more objects are added to the
repository over time, a short name that used to be unique will stop being
unique.  Git uses this many extra hexdigits that are more than necessary
to make the object name currently unique, in the hope that its output will
stay unique a bit longer.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-28 17:37:35 -07:00
Jeff King
1f2baa78c6 config: treat non-existent config files as empty
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: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-21 15:43:24 -07:00
Junio C Hamano
b815a726e9 Merge branch 'kf/askpass-config'
* kf/askpass-config:
  Extend documentation of core.askpass and GIT_ASKPASS.
  Allow core.askpass to override SSH_ASKPASS.
  Add a new option 'core.askpass'.
2010-09-08 09:17:01 -07:00
Anselm Kruis
d3e7da8979 Add a new option 'core.askpass'.
Setting this option has the same effect as setting the environment variable
'GIT_ASKPASS'.

Signed-off-by: Knut Franke <k.franke@science-computing.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-31 10:49:02 -07:00
Jeff King
2b64fc894d pass "git -c foo=bar" params through environment
Git uses the "-c foo=bar" parameters to set a config
variable for a single git invocation. We currently do this
by making a list in the current process and consulting that
list in git_config.

This works fine for built-ins, but the config changes are
silently ignored by subprocesses, including dashed externals
and invocations to "git config" from shell scripts.

This patch instead puts them in an environment variable
which we consult when looking at config (both internally and
via calls "git config").

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-24 09:53:46 -07:00
Junio C Hamano
d5cff17eda Merge branch 'eb/core-eol'
* eb/core-eol:
  Add "core.eol" config variable
  Rename the "crlf" attribute "text"
  Add per-repository eol normalization
  Add tests for per-repository eol normalization

Conflicts:
	Documentation/config.txt
	Makefile
2010-06-21 06:02:49 -07:00
Eyvind Bernhardsen
942e774767 Add "core.eol" config variable
Introduce a new configuration variable, "core.eol", that allows the user
to set which line endings to use for end-of-line-normalized files in the
working directory.  It defaults to "native", which means CRLF on Windows
and LF everywhere else.

Note that "core.autocrlf" overrides core.eol.  This means that

[core]
	autocrlf = true

puts CRLFs in the working directory even if core.eol is set to "lf".

Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-06 21:20:04 -07:00
Junio C Hamano
78f17935a3 Merge branch 'ld/discovery-limit-to-fs' (early part)
* 'ld/discovery-limit-to-fs' (early part):
  Rename ONE_FILESYSTEM to DISCOVERY_ACROSS_FILESYSTEM
  GIT_ONE_FILESYSTEM: flip the default to stop at filesystem boundaries
  Add support for GIT_ONE_FILESYSTEM
  truncate cwd string before printing error message
  config.c: remove static keyword from git_env_bool()
2010-05-21 04:02:15 -07:00
Junio C Hamano
7f3ed824a4 Merge branch 'ar/config-from-command-line'
* ar/config-from-command-line:
  Complete prototype of git_config_from_parameters()
  Use strbufs instead of open-coded string manipulation
  Allow passing of configuration parameters in the command line
2010-05-21 04:02:14 -07:00
Eyvind Bernhardsen
fd6cce9e89 Add per-repository eol normalization
Change the semantics of the "crlf" attribute so that it enables
end-of-line normalization when it is set, regardless of "core.autocrlf".

Add a new setting for "crlf": "auto", which enables end-of-line
conversion but does not override the automatic text file detection.

Add a new attribute "eol" with possible values "crlf" and "lf".  When
set, this attribute enables normalization and forces git to use CRLF or
LF line endings in the working directory, respectively.

The line ending style to be used for normalized text files in the
working directory is set using "core.autocrlf".  When it is set to
"true", CRLFs are used in the working directory; when set to "input" or
"false", LFs are used.

Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-19 20:36:15 -07:00
Alex Riesen
572e4f6a0c Use strbufs instead of open-coded string manipulation
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28 09:50:02 -07:00
Alex Riesen
8b1fa77867 Allow passing of configuration parameters in the command line
The values passed this way will override whatever is defined
in the config files.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28 09:48:25 -07:00
Lars R. Damerow
0ef37164c2 config.c: remove static keyword from git_env_bool()
Since this function is the preferred way to handle boolean environment
variables it's useful to have it available to other files.

Signed-off-by: Lars R. Damerow <lars@pixar.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-28 09:19:05 -07:00
Junio C Hamano
8420ccd8b8 git_config_maybe_bool()
Some configuration variables can take boolean values in addition to
enumeration specific to them.  Introduce git_config_maybe_bool() that
returns 0 or 1 if the given value is boolean, or -1 if not, so that
a parser for such a variable can check for boolean first and then
parse other kinds of values as a fallback.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-17 09:39:03 -08:00
Junio C Hamano
15a873d6e8 Merge branch 'jc/ident'
* jc/ident:
  ident.c: replace fprintf with fputs to suppress compiler warning
  user_ident_sufficiently_given(): refactor the logic to be usable from elsewhere
  ident.c: treat $EMAIL as giving user.email identity explicitly
  ident.c: check explicit identity for name and email separately
  ident.c: remove unused variables
2010-01-20 14:39:52 -08:00
Junio C Hamano
73d66323ac Merge branch 'nd/sparse'
* nd/sparse: (25 commits)
  t7002: test for not using external grep on skip-worktree paths
  t7002: set test prerequisite "external-grep" if supported
  grep: do not do external grep on skip-worktree entries
  commit: correctly respect skip-worktree bit
  ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
  tests: rename duplicate t1009
  sparse checkout: inhibit empty worktree
  Add tests for sparse checkout
  read-tree: add --no-sparse-checkout to disable sparse checkout support
  unpack-trees(): ignore worktree check outside checkout area
  unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
  unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
  unpack-trees.c: generalize verify_* functions
  unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
  Introduce "sparse checkout"
  dir.c: export excluded_1() and add_excludes_from_file_1()
  excluded_1(): support exclude files in index
  unpack-trees(): carry skip-worktree bit over in merged_entry()
  Read .gitignore from index if it is skip-worktree
  Avoid writing to buffer in add_excludes_from_file_1()
  ...

Conflicts:
	.gitignore
	Documentation/config.txt
	Documentation/git-update-index.txt
	Makefile
	entry.c
	t/t7002-grep.sh
2010-01-13 11:58:34 -08:00
Junio C Hamano
91c38a2108 ident.c: check explicit identity for name and email separately
bb1ae3f (commit: Show committer if automatic, 2008-05-04) added a logic to
check both name and email were given explicitly by the end user, but it
assumed that fmt_ident() is never called before git_default_user_config()
is called, which was fragile.  The former calls setup_ident() and fills
the "default" name and email, so the check in the config parser would have
mistakenly said both are given even if only user.name was provided.

Make the logic more robust by keeping track of name and email separately.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Santi Béjar <santi@agolina.net>
2010-01-10 09:42:54 -08:00
Junio C Hamano
eb2fc8f899 Merge branch 'mm/config-pathname-tilde-expand'
* mm/config-pathname-tilde-expand:
  Documentation: avoid xmlto input error
  expand_user_path: expand ~ to $HOME, not to the actual homedir.
  Expand ~ and ~user in core.excludesfile, commit.template
2009-11-22 16:28:38 -08:00
Matthieu Moy
395de250d9 Expand ~ and ~user in core.excludesfile, commit.template
These config variables are parsed to substitute ~ and ~user with getpw
entries.

user_path() refactored into new function expand_user_path(), to allow
dynamically allocating the return buffer.

Original patch by Karl Chen, modified by Matthieu Moy, and further
amended by Junio C Hamano.

Signed-off-by: Karl Chen <quarl@quarl.org>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-17 21:53:11 -08:00
Johannes Schindelin
a97a74686d Introduce commit notes
Commit notes are blobs which are shown together with the commit
message.  These blobs are taken from the notes ref, which you can
configure by the config variable core.notesRef, which in turn can
be overridden by the environment variable GIT_NOTES_REF.

The notes ref is a branch which contains "files" whose names are
the names of the corresponding commits (i.e. the SHA-1).

The rationale for putting this information into a ref is this: we
want to be able to fetch and possibly union-merge the notes,
maybe even look at the date when a note was introduced, and we
want to store them efficiently together with the other objects.

This patch has been improved by the following contributions:
- Thomas Rast: fix core.notesRef documentation
- Tor Arne Vestbø: fix printing of multi-line notes
- Alex Riesen: Using char array instead of char pointer costs less BSS
- Johan Herland: Plug leak when msg is good, but msglen or type causes return

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

get_commit_notes(): Plug memory leak when 'if' triggers, but not because of read_sha1_file() failure
2009-10-19 18:59:42 -07:00
Junio C Hamano
dc1b0c06ee Merge branch 'jk/unwanted-advices'
* jk/unwanted-advices:
  status: make "how to stage" messages optional
  push: make non-fast-forward help message configurable
2009-09-13 01:33:18 -07:00
Jim Meyering
2b7ca830c6 use write_str_in_full helper to avoid literal string lengths
In 2d14d65 (Use a clearer style to issue commands to remote helpers,
2009-09-03) I happened to notice two changes like this:

-	write_in_full(helper->in, "list\n", 5);
+
+	strbuf_addstr(&buf, "list\n");
+	write_in_full(helper->in, buf.buf, buf.len);
+	strbuf_reset(&buf);

IMHO, it would be better to define a new function,

    static inline ssize_t write_str_in_full(int fd, const char *str)
    {
           return write_in_full(fd, str, strlen(str));
    }

and then use it like this:

-       strbuf_addstr(&buf, "list\n");
-       write_in_full(helper->in, buf.buf, buf.len);
-       strbuf_reset(&buf);
+       write_str_in_full(helper->in, "list\n");

Thus not requiring the added allocation, and still avoiding
the maintenance risk of literal string lengths.
These days, compilers are good enough that strlen("literal")
imposes no run-time cost.

Transformed via this:

    perl -pi -e \
        's/write_in_full\((.*?), (".*?"), \d+\)/write_str_in_full($1, $2)/'\
      $(git grep -l 'write_in_full.*"')

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-13 01:31:10 -07:00
Jeff King
75194438f4 push: make non-fast-forward help message configurable
This message is designed to help new users understand what
has happened when refs fail to push. However, it does not
help experienced users at all, and significantly clutters
the output, frequently dwarfing the regular status table and
making it harder to see.

This patch introduces a general configuration mechanism for
optional messages, with this push message as the first
example.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-09-11 21:33:20 -07:00
Nguyễn Thái Ngọc Duy
08aefc9e47 unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
This patch introduces core.sparseCheckout, which will control whether
sparse checkout support is enabled in unpack_trees()

It also loads sparse-checkout file that will be used in the next patch.
I split it out so the next patch will be shorter, easier to read.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-23 17:14:41 -07:00
Junio C Hamano
f0df1293ac Merge branch 'maint-1.6.3' into maint
* maint-1.6.3:
  Better usage string for reflog.
  hg-to-git: don't import the unused popen2 module
  send-email: remove debug trace
  config: Keep inner whitespace verbatim
2009-08-05 12:37:24 -07:00
Björn Steinbrink
ebdaae372b config: Keep inner whitespace verbatim
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: John te Bokkel <tanj.tanj@gmail.com>
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-31 08:38:30 -07:00
Alex Vandiver
9a5abfc737 After renaming a section, print any trailing variable definitions
Signed-off-by: Alex Vandiver <alex@chmrr.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:42:44 -07:00
Alex Vandiver
a4c0d463c0 Make section_name_match start on '[', and return the length on success
Signed-off-by: Alex Vandiver <alex@chmrr.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24 23:42:34 -07:00
Felipe Contreras
4b25d091ba Fix a bunch of pointer declarations (codestyle)
Essentially; s/type* /type */ as per the coding guidelines.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-01 15:17:31 -07:00
Alex Riesen
6ffd567bec improve error message in config.c
Show errno if opening a lockfile fails.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-29 18:37:58 -07:00
Johannes Schindelin
348df16679 Rename core.unreliableHardlinks to core.createObject
"Unreliable hardlinks" is a misleading description for what is happening.
So rename it to something less misleading.

Suggested by Linus Torvalds.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-29 16:50:07 -07:00
Johannes Schindelin
be66a6c43d Add an option not to use link(src, dest) && unlink(src) when that is unreliable
It seems that accessing NTFS partitions with ufsd (at least on my EeePC)
has an unnerving bug: if you link() a file and unlink() it right away,
the target of the link() will have the correct size, but consist of NULs.

It seems as if the calls are simply not serialized correctly, as single-stepping
through the function move_temp_to_file() works flawlessly.

As ufsd is "Commertial software" (sic!), I cannot fix it, and have to work
around it in Git.

At the same time, it seems that this fixes msysGit issues 222 and 229 to
assume that Windows cannot handle link() && unlink().

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-25 09:49:21 -07:00
Junio C Hamano
4f760b74cf Merge branch 'lt/bool-on-off'
* lt/bool-on-off:
  Documentation: boolean value may be given by on/off
  Allow users to un-configure rename detection
2009-04-18 14:46:22 -07:00
Junio C Hamano
2d430c7133 Merge branch 'maint'
* maint:
  doc/gitattributes: clarify location of config text
  Fix buffer overflow in config parser
  git-apply: fix option description
2009-04-17 21:29:15 -07:00
Junio C Hamano
f7446fc6bb Merge branch 'maint-1.6.1' into maint
* maint-1.6.1:
  Fix buffer overflow in config parser
2009-04-17 21:20:58 -07:00
Junio C Hamano
0fa0514b91 Merge branch 'maint-1.6.0' into maint-1.6.1
* maint-1.6.0:
  Fix buffer overflow in config parser
2009-04-17 21:06:11 -07:00
Thomas Jarosch
e0b3cc0dff Fix buffer overflow in config parser
When interpreting a config value, the config parser reads in 1+ space
character(s) and puts -one- space character in the buffer as soon as
the first non-space character is encountered (if not inside quotes).

Unfortunately the buffer size check lacks the extra space character
which gets inserted at the next non-space character, resulting in
a crash with a specially crafted config entry.

The unit test now uses Java to compile a platform independent
.NET framework to output the test string in C# :o)

    Read: Thanks to Johannes Sixt for the correct printf call
    which replaces the perl invocation.

Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-17 20:59:01 -07:00
Linus Torvalds
8f8c6fafd9 Allow users to un-configure rename detection
On Thu, 9 Apr 2009, Linus Torvalds wrote:
>
> 	[diff]
> 		renames = no

Btw, while doing this, I also though that "renames = on/off" made more
sense, but while we allow yes/no and true/false for booleans, we don't
allow on/off.

Should we? Maybe. Here's a stupid patch.

		Linus

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-11 11:00:45 -07:00
Junio C Hamano
2545c089e3 Merge branch 'fg/push-default'
* fg/push-default:
  builtin-push.c: Fix typo: "anythig" -> "anything"
  Display warning for default git push with no push.default config
  New config push.default to decide default behavior for push

Conflicts:
	Documentation/config.txt
2009-03-26 00:26:25 -07:00
Junio C Hamano
17e46ea6fe Merge branch 'fc/parseopt-config'
* fc/parseopt-config:
  config: test for --replace-all with one argument and fix documentation.
  config: set help text for --bool-or-int
  git config: don't allow --get-color* and variable type
  git config: don't allow extra arguments for -e or -l.
  git config: don't allow multiple variable types
  git config: don't allow multiple config file locations
  git config: reorganize to use parseopt
  git config: reorganize get_color*
  git config: trivial rename in preparation for parseopt
  git_config(): not having a per-repo config file is not an error
2009-03-20 14:29:03 -07:00
Finn Arne Gangstad
521537476f New config push.default to decide default behavior for push
When "git push" is not told what refspecs to push, it pushes all matching
branches to the current remote.  For some workflows this default is not
useful, and surprises new users.  Some have even found that this default
behaviour is too easy to trigger by accident with unwanted consequences.

Introduce a new configuration variable "push.default" that decides what
action git push should take if no refspecs are given or implied by the
command line arguments or the current remote configuration.

Possible values are:

  'nothing'  : Push nothing;
  'matching' : Current default behaviour, push all branches that already
               exist in the current remote;
  'tracking' : Push the current branch to whatever it is tracking;
  'current'  : Push the current branch to a branch of the same name,
               i.e. HEAD.

Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-17 14:50:21 -07:00
Felipe Contreras
aa38740791 git_config(): not having a per-repo config file is not an error
Currently git_config() returns an error if there is no repo config file
available (cwd is not a git repo); it will correctly parse the system
and global config files, but still return an error.

It doesn't affect anything else since almost nobody is checking for the
return code (with the exception of 'git remote update').

A reorganization in 'git config' would benefit from being able to
properly detect errors in git_config() without the noise generated when
cwd is not a git repo.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-21 20:35:50 -08:00
Marius Storm-Olsen
d551a48816 Add mailmap.file as configurational option for mailmap location
This allows us to augment the repo mailmap file, and to use
mailmap files elsewhere than the repository root. Meaning
that the entries in mailmap.file will override the entries
in "./.mailmap", should they match.

Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-08 12:36:26 -08:00
Johannes Schindelin
879ef2485d Introduce commit notes
Commit notes are blobs which are shown together with the commit
message.  These blobs are taken from the notes ref, which you can
configure by the config variable core.notesRef, which in turn can
be overridden by the environment variable GIT_NOTES_REF.

The notes ref is a branch which contains "files" whose names are
the names of the corresponding commits (i.e. the SHA-1).

The rationale for putting this information into a ref is this: we
want to be able to fetch and possibly union-merge the notes,
maybe even look at the date when a note was introduced, and we
want to store them efficiently together with the other objects.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-21 02:47:21 -08:00
Johannes Schindelin
8befc50c49 Get rid of the last remnants of GIT_CONFIG_LOCAL
In dc871831(Only use GIT_CONFIG in "git config", not other programs),
GIT_CONFIG_LOCAL was rested in peace, in favor of not reading
/etc/gitconfig and $HOME/.gitconfig at all when GIT_CONFIG is set.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-12-14 16:43:39 -08:00
Linus Torvalds
671c9b7e31 Add cache preload facility
This can do the lstat() storm in parallel, giving potentially much
improved performance for cold-cache cases or things like NFS that have
weak metadata caching.

Just use "read_cache_preload()" instead of "read_cache()" to force an
optimistic preload of the index stat data.  The function takes a
pathspec as its argument, allowing us to preload only the relevant
portion of the index.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-14 19:11:49 -08:00
Junio C Hamano
98b35e2c74 Merge branch 'ar/maint-mksnpath' into ar/mksnpath
* ar/maint-mksnpath:
  Use git_pathdup instead of xstrdup(git_path(...))
  git_pathdup: returns xstrdup-ed copy of the formatted path
  Fix potentially dangerous use of git_path in ref.c
  Add git_snpath: a .git path formatting routine with output buffer

Conflicts:
	builtin-revert.c
	refs.c
	rerere.c
2008-10-30 18:08:58 -07:00
Alex Riesen
a4f34cbb4c Use git_pathdup instead of xstrdup(git_path(...))
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-30 17:52:24 -07:00
Brandon Casey
f285a2d7ed Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializer
Many call sites use strbuf_init(&foo, 0) to initialize local
strbuf variable "foo" which has not been accessed since its
declaration. These can be replaced with a static initialization
using the STRBUF_INIT macro which is just as readable, saves a
function call, and takes up fewer lines.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-12 12:36:19 -07:00
Nanako Shiraishi
0433bcd9f0 config.c: make git_parse_long() static
This function is not used in any other file.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-02 18:03:35 -07:00
Petr Baudis
de056402fd config.c: Tolerate UTF8 BOM at the beginning of config file
Unfortunately, the abomination of Windows Notepad likes to scatted
non-sensical UTF8 BOM marks across text files it edits. This is
especially troublesome when editing the Git configuration file,
and it does not appear to be particularly harmful to teach Git
to deal with this poo in the configfile.

Signed-off-by: Petr Baudis <petr.baudis@novartis.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-02 17:19:03 -07:00
Alex Riesen
1ce4790bf5 Make use of stat.ctime configurable
A new configuration variable 'core.trustctime' is introduced to
allow ignoring st_ctime information when checking if paths
in the working tree has changed, because there are situations where
it produces too much false positives.  Like when file system crawlers
keep changing it when scanning and using the ctime for marking scanned
files.

The default is to notice ctime changes.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-28 23:26:25 -07:00
Steffen Prohaska
2de9de5e4a Move code interpreting path relative to exec-dir to new function system_path()
Expanding system paths relative to git_exec_path can be used for
creating an installation that can be moved to a different directory
without re-compiling.  We use this approach for template_dir and the
system wide gitconfig.  The Windows installer (msysgit) is an example
for such a setup.

This commit moves common code to a new function system_path().  System
paths that are to be interpreted relative to git_exec_path are passed to
system_path() and the return value is used instead of the original path.
system_path() prefixes a relative path with git_exec_path and leaves
absolute paths unmodified.  For example, we now write

    template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);

[j6t: moved from path.c to exec_cmd.c]

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13 14:41:28 -07:00
Daniel Barkalow
dc87183189 Only use GIT_CONFIG in "git config", not other programs
For everything other than using "git config" to read or write a
git-style config file that isn't the current repo's config file,
GIT_CONFIG was actively detrimental. Rather than argue over which
programs are important enough to have work anyway, just fix all of
them at the root.

Also removes GIT_LOCAL_CONFIG, which would only be useful for programs
that do want to use global git-specific config, but not the repo's own
git-specific config, and want to use some other, presumably
git-specific config. Despite being documented, I can't find any sign that
it was ever used.

Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-01 02:35:49 -07:00
Junio C Hamano
abf7e0df17 Merge branch 'lt/config-fsync'
* lt/config-fsync:
  Add config option to enable 'fsync()' of object files
  Split up default "i18n" and "branch" config parsing into helper routines
  Split up default "user" config parsing into helper routine
  Split up default "core" config parsing into helper routine
2008-06-25 13:19:49 -07:00
しらいしななこ
e4bffb5a1d config.c: make git_env_bool() static
This function is not used by any other file.

Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-19 17:07:41 -07:00
Linus Torvalds
aafe9fbaf4 Add config option to enable 'fsync()' of object files
As explained in the documentation[*] this is totally useless on
filesystems that do ordered/journalled data writes, but it can be a
useful safety feature on filesystems like HFS+ that only journal the
metadata, not the actual file contents.

It defaults to off, although we could presumably in theory some day
auto-enable it on a per-filesystem basis.

[*] Yes, I updated the docs for the thing.  Hell really _has_ frozen
    over, and the four horsemen are probably just beyond the horizon.
    EVERYBODY PANIC!

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-18 16:50:35 -07:00
Linus Torvalds
1141f4925c Split up default "i18n" and "branch" config parsing into helper routines
.. just to finish it off.  We'll leave the pager color config alone,
since it is such an odd-ball special case anyway.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-18 16:50:32 -07:00
Linus Torvalds
d1364529d0 Split up default "user" config parsing into helper routine
This follows the example of the "core" config, and splits out the
default "user" config option parsing into a helper routine.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-18 16:50:23 -07:00
Linus Torvalds
806e2ad7fe Split up default "core" config parsing into helper routine
It makes the code a bit easier to read, and in theory a bit faster too
(no need to compare all the different "core.*" strings against non-core
config options).

The config system really should get something of a complete overhaul,
but in the absense of that, this at least improves on it a tiny bit.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-18 16:50:22 -07:00
Junio C Hamano
9bd81e4249 Merge branch 'js/config-cb'
* js/config-cb:
  Provide git_config with a callback-data parameter

Conflicts:

	builtin-add.c
	builtin-cat-file.c
2008-05-25 14:25:02 -07:00
Junio C Hamano
b66ae7955c Merge branch 'sb/committer'
* sb/committer:
  commit: Show committer if automatic
  commit: Show author if different from committer
  Preparation to call determine_author_info from prepare_to_commit
2008-05-14 13:45:20 -07:00
Junio C Hamano
761adeb4db Merge branch 'bd/tests'
* bd/tests:
  Rename the test trash directory to contain spaces.
  Fix tests breaking when checkout path contains shell metacharacters
  Don't use the 'export NAME=value' in the test scripts.
  lib-git-svn.sh: Fix quoting issues with paths containing shell metacharacters
  test-lib.sh: Fix some missing path quoting
  Use test_set_editor in t9001-send-email.sh
  test-lib.sh: Add a test_set_editor function to safely set $VISUAL
  git-send-email.perl: Handle shell metacharacters in $EDITOR properly
  config.c: Escape backslashes in section names properly
  git-rebase.sh: Fix --merge --abort failures when path contains whitespace

Conflicts:

	t/t9115-git-svn-dcommit-funky-renames.sh
2008-05-14 13:45:16 -07:00