Commit Graph

156 Commits

Author SHA1 Message Date
Shawn O. Pearce
c8deb5a146 Improve error messages when int/long cannot be parsed from config
If a config file has become mildly corrupted due to a missing LF
we may discover some other option joined up against the end of a
numeric value.  For example:

	[section]
	number = 1auto

where the "auto" flag was meant to occur on the next line, below
"number", but the missing LF has caused it to no longer be its
own option.  Instead the word "auto" is parsed as a 'unit factor'
for the value of "number".

Before this change we got the confusing error message:

  fatal: unknown unit: 'auto'

which told us nothing about where the problem appeared.  Now we get:

  fatal: bad config value for 'aninvalid.unit'

which at least points the user in the right direction of where to
search for the incorrectly formatted configuration file.

Noticed by erikh on #git, which received the original error from
a simple `git checkout -b` due to a midly corrupted config.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-26 11:37:45 -08:00
Kristian Høgsberg
cb891a5989 Use a strbuf for building up section header and key/value pair strings.
Avoids horrible 1-byte write(2) calls and cleans up the logic a bit.

Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-14 20:42:26 -08:00
Junio C Hamano
4eb39e9bcc Merge branch 'jc/spht'
* jc/spht:
  Use gitattributes to define per-path whitespace rule
  core.whitespace: documentation updates.
  builtin-apply: teach whitespace_rules
  builtin-apply: rename "whitespace" variables and fix styles
  core.whitespace: add test for diff whitespace error highlighting
  git-diff: complain about >=8 consecutive spaces in initial indent
  War on whitespace: first, a bit of retreat.

Conflicts:

	cache.h
	config.c
	diff.c
2007-12-09 01:23:48 -08:00
Junio C Hamano
9b433e4496 Merge branch 'maint'
* maint:
  config.c:store_write_pair(): don't read the byte before a malloc'd buffer.
2007-12-09 00:56:44 -08:00
Jim Meyering
6281f39467 config.c:store_write_pair(): don't read the byte before a malloc'd buffer.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-08 14:24:13 -08:00
Junio C Hamano
cf1b7869f0 Use gitattributes to define per-path whitespace rule
The `core.whitespace` configuration variable allows you to define what
`diff` and `apply` should consider whitespace errors for all paths in
the project (See gitlink:git-config[1]).  This attribute gives you finer
control per path.

For example, if you have these in the .gitattributes:

    frotz   whitespace
    nitfol  -whitespace
    xyzzy   whitespace=-trailing

all types of whitespace problems known to git are noticed in path 'frotz'
(i.e. diff shows them in diff.whitespace color, and apply warns about
them), no whitespace problem is noticed in path 'nitfol', and the
default types of whitespace problems except "trailing whitespace" are
noticed for path 'xyzzy'.  A project with mixed Python and C might want
to have:

    *.c    whitespace
    *.py   whitespace=-indent-with-non-tab

in its toplevel .gitattributes file.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06 00:45:30 -08:00
Junio C Hamano
dcf0c16ef1 core.excludesfile clean-up
There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable.  The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.

 * git-ls-files does not notice any of the "ignore" files by
   default, as it predates the standardized set of ignore files.
   The calling scripts established the convention to use
   .git/info/exclude, .gitignore, and later core.excludesfile.

 * git-add and git-status know about it because they call
   add_excludes_from_file() directly with their own notion of
   which standard set of ignore files to use.  This is just a
   stupid duplication of code that need to be updated every time
   the definition of the standard set of ignore files is
   changed.

 * git-read-tree takes --exclude-per-directory=<gitignore>,
   not because the flexibility was needed.  Again, this was
   because the option predates the standardization of the ignore
   files.

 * git-merge-recursive uses hardcoded per-directory .gitignore
   and nothing else.  git-clean (scripted version) does not
   honor core.* because its call to underlying ls-files does not
   know about it.  git-clean in C (parked in 'pu') doesn't either.

We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way.  I am somewhat reluctant to make such a change.

On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands.  I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.

This patch is the first step to untangle this mess.

The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-16 17:05:02 -08:00
Johannes Sixt
7f0e39faa2 Allow ETC_GITCONFIG to be a relative path.
If ETC_GITCONFIG is not an absolute path, interpret it relative to
--exec-dir. This makes the installed binaries relocatable because the
prefix is not compiled-in.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14 15:18:39 -08:00
Johannes Sixt
506b17b136 Introduce git_etc_gitconfig() that encapsulates access of ETC_GITCONFIG.
In a subsequent patch the path to the system-wide config file will be
computed. This is a preparation for that change. It turns all accesses
of ETC_GITCONFIG into function calls. There is no change in behavior.

As a consequence, config.c is the only file that needs the definition of
ETC_GITCONFIG. Hence, -DETC_GITCONFIG is removed from the CFLAGS and a
special build rule for config.c is introduced. As a side-effect, changing
the defintion of ETC_GITCONFIG (e.g. in config.mak) does not trigger a
complete rebuild anymore.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14 15:18:39 -08:00
Junio C Hamano
039bc64e88 core.excludesfile clean-up
There are inconsistencies in the way commands currently handle
the core.excludesfile configuration variable.  The problem is
the variable is too new to be noticed by anything other than
git-add and git-status.

 * git-ls-files does not notice any of the "ignore" files by
   default, as it predates the standardized set of ignore files.
   The calling scripts established the convention to use
   .git/info/exclude, .gitignore, and later core.excludesfile.

 * git-add and git-status know about it because they call
   add_excludes_from_file() directly with their own notion of
   which standard set of ignore files to use.  This is just a
   stupid duplication of code that need to be updated every time
   the definition of the standard set of ignore files is
   changed.

 * git-read-tree takes --exclude-per-directory=<gitignore>,
   not because the flexibility was needed.  Again, this was
   because the option predates the standardization of the ignore
   files.

 * git-merge-recursive uses hardcoded per-directory .gitignore
   and nothing else.  git-clean (scripted version) does not
   honor core.* because its call to underlying ls-files does not
   know about it.  git-clean in C (parked in 'pu') doesn't either.

We probably could change git-ls-files to use the standard set
when no excludes are specified on the command line and ignore
processing was asked, or something like that, but that will be a
change in semantics and might break people's scripts in a subtle
way.  I am somewhat reluctant to make such a change.

On the other hand, I think it makes perfect sense to fix
git-read-tree, git-merge-recursive and git-clean to follow the
same rule as other commands.  I do not think of a valid use case
to give an exclude-per-directory that is nonstandard to
read-tree command, outside a "negative" test in the t1004 test
script.

This patch is the first step to untangle this mess.

The next step would be to teach read-tree, merge-recursive and
clean (in C) to use setup_standard_excludes().

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14 15:08:04 -08:00
Junio C Hamano
459fa6d0fe git-diff: complain about >=8 consecutive spaces in initial indent
This introduces a new whitespace error type, "indent-with-non-tab".
The error is about starting a line with 8 or more SP, instead of
indenting it with a HT.

This is not enabled by default, as some projects employ an
indenting policy to use only SPs and no HTs.

The kernel folks and git contributors may want to enable this
detection with:

	[core]
		whitespace = indent-with-non-tab

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02 17:58:09 -07:00
Junio C Hamano
a9cc857ada War on whitespace: first, a bit of retreat.
This introduces core.whitespace configuration variable that lets
you specify the definition of "whitespace error".

Currently there are two kinds of whitespace errors defined:

 * trailing-space: trailing whitespaces at the end of the line.

 * space-before-tab: a SP appears immediately before HT in the
   indent part of the line.

You can specify the desired types of errors to be detected by
listing their names (unique abbreviations are accepted)
separated by comma.  By default, these two errors are always
detected, as that is the traditional behaviour.  You can disable
detection of a particular type of error by prefixing a '-' in
front of the name of the error, like this:

	[core]
		whitespace = -trailing-space

This patch teaches the code to output colored diff with
DIFF_WHITESPACE color to highlight the detected whitespace
errors to honor the new configuration.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-02 17:58:08 -07:00
Junio C Hamano
55d1932bce Merge branch 'cr/tag'
* cr/tag:
  Teach "git stripspace" the --strip-comments option
  Make verify-tag a builtin.
  builtin-tag.c: Fix two memory leaks and minor notation changes.
  launch_editor(): Heed GIT_EDITOR and core.editor settings
  Make git tag a builtin.
2007-08-10 23:17:46 -07:00
Bradford C. Smith
6cbf973c9a use lockfile.c routines in git_commit_set_multivar()
Changed git_commit_set_multivar() to use the routines provided by
lockfile.c to reduce code duplication and ensure consistent behavior.

Signed-off-by: Bradford C. Smith <bradford.carl.smith@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-27 00:02:05 -07:00
Johannes Schindelin
4d87b9c5db launch_editor(): Heed GIT_EDITOR and core.editor settings
In the commit 'Add GIT_EDITOR environment and core.editor
configuration variables', this was done for the shell scripts.
Port it over to builtin-tag's version of launch_editor(), which
is just about to be refactored into editor.c.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-21 16:51:14 -07:00
Brian Downing
0b87b6e081 Add functions for parsing integers with size suffixes
Split out the nnn{k,m,g} parsing code from git_config_int into
git_parse_long, so command-line parameters can enjoy the same
functionality.  Also add get_parse_ulong for unsigned values.

Make git_config_int use git_parse_long, and add get_config_ulong
as well.

Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-12 14:32:35 -07:00
Brian Gernhardt
54adf3706c Add core.pager config variable.
This adds a configuration variable that performs the same function as,
but is overridden by, GIT_PAGER.

Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Acked-by: Johannes E. Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-04 10:09:32 -07:00
Junio C Hamano
9378c16135 Add core.quotepath configuration variable.
We always quote "unusual" byte values in a pathname using
C-string style, to make it safer for parsing scripts that do not
handle NUL separated records well (or just too lazy to bother).
The absolute minimum bytes that need to be quoted for this
purpose are TAB, LF (and other control characters), double quote
and backslash.

However, we have also always quoted the bytes in high 8-bit
range; this was partly because we were lazy and partly because
we were being cautious.

This introduces an internal "quote_path_fully" variable, and
core.quotepath configuration variable to control it.  When set
to false, it does not quote bytes in high 8-bit range anymore
but passes them intact.

The variable defaults to "true" to retain the traditional
behaviour for now.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-24 15:11:42 -07:00
Junio C Hamano
b79d18c92d -Wold-style-definition fix
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-13 02:02:10 -07:00
Junio C Hamano
a6080a0a44 War on whitespace
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time.  There are a few files that need
to have trailing whitespaces (most notably, test vectors).  The results
still passes the test, and build result in Documentation/ area is unchanged.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-07 00:04:01 -07:00
Junio C Hamano
45bde46bfb Merge branch 'dh/pack'
* dh/pack:
  Custom compression levels for objects and packs
2007-05-20 02:19:19 -07:00
Junio C Hamano
cc93020f52 Merge branch 'np/pack'
* np/pack:
  deprecate the new loose object header format
  make "repack -f" imply "pack-objects --no-reuse-object"
  allow for undeltified objects not to be reused
2007-05-20 02:18:43 -07:00
Junio C Hamano
ae9ee41de8 git-config: do not forget seeing "a.b.var" means we are out of "a.var" section.
Earlier code tried to be half-careful and knew the logic that
seeing "a.var" after seeing "a.b.var" is a sign of the previous
"a.b." section has ended, but forgot it has to handle the other
way.  Seeing "a.b.var" after seeing "a.var" is a sign that "a."
section has ended, so a new "a.var2" variable should be added
before the location "a.b.var" appears.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-13 00:19:58 -07:00
Dana How
960ccca680 Custom compression levels for objects and packs
Add config variables pack.compression and core.loosecompression ,
and switch --compression=level to pack-objects.

Loose objects will be compressed using core.loosecompression if set,
else core.compression if set, else Z_BEST_SPEED.
Packed objects will be compressed using --compression=level if seen,
else pack.compression if set, else core.compression if set,
else Z_DEFAULT_COMPRESSION.  This is the "pack compression level".

Loose objects added to a pack undeltified will be recompressed
to the pack compression level if it is unequal to the current
loose compression level by the preceding rules,  or if the loose
object was written while core.legacyheaders = true.  Newly
deltified loose objects are always compressed to the current
pack compression level.

Previously packed objects added to a pack are recompressed
to the current pack compression level exactly when their
deltification status changes,  since the previous pack data
cannot be reused.

In either case,  the --no-reuse-object switch from the first
patch below will always force recompression to the current pack
compression level,  instead of assuming the pack compression level
hasn't changed and pack data can be reused when possible.

This applies on top of the following patches from Nicolas Pitre:
[PATCH] allow for undeltified objects not to be reused
[PATCH] make "repack -f" imply "pack-objects --no-reuse-object"

Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-10 15:23:09 -07:00
Nicolas Pitre
726f852b0e deprecate the new loose object header format
Now that we encourage and actively preserve objects in a packed form
more agressively than we did at the time the new loose object format and
core.legacyheaders were introduced, that extra loose object format
doesn't appear to be worth it anymore.

Because the packing of loose objects has to go through the delta match
loop anyway, and since most of them should end up being deltified in
most cases, there is really little advantage to have this parallel loose
object format as the CPU savings it might provide is rather lost in the
noise in the end.

This patch gets rid of core.legacyheaders, preserve the legacy format as
the only writable loose object format and deprecate the other one to
keep things simpler.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-10 15:22:33 -07:00
Geert Bosch
01ebb9dc88 Fix renaming branch without config file
Make git_config_rename_section return success if no config file
exists.  Otherwise, renaming a branch would abort, leaving the
repository in an inconsistent state.

[jc: test]

Signed-off-by: Geert Bosch <bosch@gnat.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-05 14:53:22 -07:00
Shawn O. Pearce
18bdec1118 Limit the size of the new delta_base_cache
The new configuration variable core.deltaBaseCacheLimit allows the
user to control how much memory they are willing to give to Git for
caching base objects of deltas.  This is not normally meant to be
a user tweakable knob; the "out of the box" settings are meant to
be suitable for almost all workloads.

We default to 16 MiB under the assumption that the cache is not
meant to consume all of the user's available memory, and that the
cache's main purpose was to cache trees, for faster path limiters
during revision traversal.  Since trees tend to be relatively small
objects, this relatively small limit should still allow a large
number of objects.

On the other hand we don't want the cache to start storing 200
different versions of a 200 MiB blob, as this could easily blow
the entire address space of a 32 bit process.

We evict OBJ_BLOB from the cache first (credit goes to Junio) as
we want to favor OBJ_TREE within the cache.  These are the objects
that have the highest inflate() startup penalty, as they tend to
be small and thus don't have that much of a chance to ammortize
that penalty over the entire data.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-18 22:43:37 -07:00
Shawn O. Pearce
dbb2b41aa4 use xstrdup please
We generally prefer xstrdup to just plain strdup.
Make it so.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-16 02:12:14 -07:00
Junio C Hamano
bd1fc628b8 Merge branch 'js/config-rename'
* js/config-rename:
  git-config: document --rename-section, provide --remove-section
2007-03-08 00:53:38 -08:00
Shawn O. Pearce
dc49cd769b Cast 64 bit off_t to 32 bit size_t
Some systems have sizeof(off_t) == 8 while sizeof(size_t) == 4.
This implies that we are able to access and work on files whose
maximum length is around 2^63-1 bytes, but we can only malloc or
mmap somewhat less than 2^32-1 bytes of memory.

On such a system an implicit conversion of off_t to size_t can cause
the size_t to wrap, resulting in unexpected and exciting behavior.
Right now we are working around all gcc warnings generated by the
-Wshorten-64-to-32 option by passing the off_t through xsize_t().

In the future we should make xsize_t on such problematic platforms
detect the wrapping and die if such a file is accessed.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-07 11:15:26 -08:00
Paolo Bonzini
118f8b2413 git-config: document --rename-section, provide --remove-section
This patch documents the previously undocumented option --rename-section
and adds a new option to zap an entire section.

Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-03 19:59:37 -08:00
Johannes Sixt
78a8d641c1 Add core.symlinks to mark filesystems that do not support symbolic links.
Some file systems that can host git repositories and their working copies
do not support symbolic links. But then if the repository contains a symbolic
link, it is impossible to check out the working copy.

This patch enables partial support of symbolic links so that it is possible
to check out a working copy on such a file system.  A new flag
core.symlinks (which is true by default) can be set to false to indicate
that the filesystem does not support symbolic links. In this case, symbolic
links that exist in the trees are checked out as small plain files, and
checking in modifications of these files preserve the symlink property in
the database (as long as an entry exists in the index).

Of course, this does not magically make symbolic links work on such defective
file systems; hence, this solution does not help if the working copy relies
on that an entry is a real symbolic link.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-02 16:58:05 -08:00
Junio C Hamano
cc58fc0684 Merge branch 'js/etc-config'
* js/etc-config:
  Make tests independent of global config files
  config: read system-wide defaults from /etc/gitconfig
2007-02-24 01:43:28 -08:00
Junio C Hamano
ef1a5c2fa8 Merge branches 'lt/crlf' and 'jc/apply-config'
* lt/crlf:
  Teach core.autocrlf to 'git apply'
  t0020: add test for auto-crlf
  Make AutoCRLF ternary variable.
  Lazy man's auto-CRLF

* jc/apply-config:
  t4119: test autocomputing -p<n> for traditional diff input.
  git-apply: guess correct -p<n> value for non-git patches.
  git-apply: notice "diff --git" patch again
  Fix botched "leak fix"
  t4119: add test for traditional patch and different p_value
  apply: fix memory leak in prefix_one()
  git-apply: require -p<n> when working in a subdirectory.
  git-apply: do not lose cwd when run from a subdirectory.
  Teach 'git apply' to look at $HOME/.gitconfig even outside of a repository
  Teach 'git apply' to look at $GIT_DIR/config
2007-02-22 21:34:36 -08:00
Johannes Schindelin
32043c9f8c config: read system-wide defaults from /etc/gitconfig
The settings in /etc/gitconfig can be overridden in ~/.gitconfig,
which in turn can be overridden in .git/config.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-19 23:05:16 -08:00
Junio C Hamano
5faaf24634 Make sure packedgitwindowsize is multiple of (pagesize * 2)
The next patch depends on this.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14 13:20:41 -08:00
Linus Torvalds
d7f4633405 Make AutoCRLF ternary variable.
This allows you to do:

	[core]
		AutoCRLF = input

and it should do only the CRLF->LF translation (ie it simplifies CRLF only
when reading working tree files, but when checking out files, it leaves
the LF alone, and doesn't turn it into a CRLF).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14 11:19:28 -08:00
Linus Torvalds
6c510bee20 Lazy man's auto-CRLF
It currently does NOT know about file attributes, so it does its
conversion purely based on content. Maybe that is more in the "git
philosophy" anyway, since content is king, but I think we should try to do
the file attributes to turn it off on demand.

Anyway, BY DEFAULT it is off regardless, because it requires a

	[core]
		AutoCRLF = true

in your config file to be enabled. We could make that the default for
Windows, of course, the same way we do some other things (filemode etc).

But you can actually enable it on UNIX, and it will cause:

 - "git update-index" will write blobs without CRLF
 - "git diff" will diff working tree files without CRLF
 - "git checkout" will write files to the working tree _with_ CRLF

and things work fine.

Funnily, it actually shows an odd file in git itself:

	git clone -n git test-crlf
	cd test-crlf
	git config core.autocrlf true
	git checkout
	git diff

shows a diff for "Documentation/docbook-xsl.css". Why? Because we have
actually checked in that file *with* CRLF! So when "core.autocrlf" is
true, we'll always generate a *different* hash for it in the index,
because the index hash will be for the content _without_ CRLF.

Is this complete? I dunno. It seems to work for me. It doesn't use the
filename at all right now, and that's probably a deficiency (we could
certainly make the "is_binary()" heuristics also take standard filename
heuristics into account).

I don't pass in the filename at all for the "index_fd()" case
(git-update-index), so that would need to be passed around, but this
actually works fine.

NOTE NOTE NOTE! The "is_binary()" heuristics are totally made-up by yours
truly. I will not guarantee that they work at all reasonable. Caveat
emptor. But it _is_ simple, and it _is_ safe, since it's all off by
default.

The patch is pretty simple - the biggest part is the new "convert.c" file,
but even that is really just basic stuff that anybody can write in
"Teaching C 101" as a final project for their first class in programming.
Not to say that it's bug-free, of course - but at least we're not talking
about rocket surgery here.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14 11:19:22 -08:00
Pavel Roskin
9673a0b182 git-config --rename-section could rename wrong section
The "git-config --rename-section" implementation would match sections
that are substrings of the section name to be renamed.

Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-03 21:35:22 -08:00
Johannes Schindelin
6f71686e0b config_set_multivar(): disallow newlines in keys
This will no longer work:

$ git repo-config 'key.with
newline' some-value

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2007-01-19 17:55:14 -08:00
Junio C Hamano
e861ce1692 Merge branch 'jc/bare'
* jc/bare:
  Disallow working directory commands in a bare repository.
  git-fetch: allow updating the current branch in a bare repository.
  Introduce is_bare_repository() and core.bare configuration variable
  Move initialization of log_all_ref_updates
2007-01-11 16:50:36 -08:00
Junio C Hamano
93c1e07947 config-set: check write-in-full returns in set_multivar
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-11 13:19:31 -08:00
Brian Gernhardt
cdd4fb15cf Auto-quote config values in config.c:store_write_pair()
Suggested by Jakub Narebski <jnareb@gmail.com> on the list.

When we send a value to store_write_pair(), make sure that the value
that gets read out matches the one passed in.  This means that for any
value that contains leading or trailing whitespace or any comment
character (# and ;), we need to surround it in quotes.

Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-08 22:00:18 -08:00
Andy Whitcroft
480c9e521b short i/o: fix config updates to use write_in_full
We need to check that the writes we perform during the update of
the users configuration work.  Convert to using write_in_full().

Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-08 15:44:47 -08:00
Junio C Hamano
7d1864ce67 Introduce is_bare_repository() and core.bare configuration variable
This removes the old is_bare_git_dir(const char *) to ask if a
directory, if it is a GIT_DIR, is a bare repository, and
replaces it with is_bare_repository(void *).  The function looks
at core.bare configuration variable if exists but uses the old
heuristics: if it is ".git" or ends with "/.git", then it does
not look like a bare repository, otherwise it does.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-07 21:36:35 -08:00
Junio C Hamano
76d4e079ad Merge branch 'master' into sp/mmap
* master:
  Documentation/config.txt (and repo-config manpage): mark-up fix.
  Teach Git how to parse standard power of 2 suffixes.
  Use /dev/null for update hook stdin.
  Redirect update hook stdout to stderr.
  Remove unnecessary argc parameter from run_command_v.
  Automatically detect a bare git repository.
  Replace "GIT_DIR" with GIT_DIR_ENVIRONMENT.
  Use PATH_MAX constant for --bare.
  Force core.filemode to false on Cygwin.
  Fix formatting for urls section of fetch, pull, and push manpages
  Fix yet another subtle xdl_merge() bug
  i18n: drop "encoding" header in the output after re-coding.
  commit-tree: cope with different ways "utf-8" can be spelled.
  Move commit reencoding parameter parsing to revision.c
  Documentation: minor rewording for git-log and git-show pages.
  Documentation: i18n commit log message notes.
  t3900: test log --encoding=none
  commit re-encoding: fix confusion between no and default conversion.
2006-12-30 22:42:43 -08:00
Shawn O. Pearce
d77a64d353 Teach Git how to parse standard power of 2 suffixes.
Sometimes its necessary to supply a value as a power of two in a
configuration parameter.  In this case the user may want to use the
standard suffixes such as K, M, or G to indicate that the numerical
value should be multiplied by a constant base before being used.

Shell scripts/etc. can also benefit from this automatic option
parsing with `git repo-config --int`.

[jc: with a couple of test and a slight input tightening]

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-30 22:22:14 -08:00
Shawn O. Pearce
c4712e4553 Replace mmap with xmmap, better handling MAP_FAILED.
In some cases we did not even bother to check the return value of
mmap() and just assume it worked.  This is bad, because if we are
out of virtual address space the kernel returned MAP_FAILED and we
would attempt to dereference that address, segfaulting without any
real error output to the user.

We are replacing all calls to mmap() with xmmap() and moving all
MAP_FAILED checking into that single location.  If a mmap call
fails we try to release enough least-recently-used pack windows
to possibly succeed, then retry the mmap() attempt.  If we cannot
mmap even after releasing pack memory then we die() as none of our
callers have any reasonable recovery strategy for a failed mmap.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-29 11:36:45 -08:00
Shawn O. Pearce
40be82723c Ensure core.packedGitWindowSize cannot be less than 2 pages.
We cannot allow a window to be smaller than 2 system pages.
This limitation is necessary to support the feature of use_pack()
where we always supply at least 20 bytes after the offset to help
the object header and delta base parsing routines.

If packedGitWindowSize were allowed to be as small as 1 system page
then we would be completely unable to access an object header which
spanned over a page as we would never be able to arrange a mapping
such that the header was contiguous in virtual memory.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-29 11:36:45 -08:00
Shawn O. Pearce
60bb8b1453 Fully activate the sliding window pack access.
This finally turns on the sliding window behavior for packfile data
access by mapping limited size windows and chaining them under the
packed_git->windows list.

We consider a given byte offset to be within the window only if there
would be at least 20 bytes (one hash worth of data) accessible after
the requested offset.  This range selection relates to the contract
that use_pack() makes with its callers, allowing them to access
one hash or one object header without needing to call use_pack()
for every byte of data obtained.

In the worst case scenario we will map the same page of data twice
into memory: once at the end of one window and once again at the
start of the next window.  This duplicate page mapping will happen
only when an object header or a delta base reference is spanned
over the end of a window and is always limited to just one page of
duplication, as no sane operating system will ever have a page size
smaller than a hash.

I am assuming that the possible wasted page of virtual address
space is going to perform faster than the alternatives, which
would be to copy the object header or ref delta into a temporary
buffer prior to parsing, or to check the window range on every byte
during header parsing.  We may decide to revisit this decision in
the future since this is just a gut instinct decision and has not
actually been proven out by experimental testing.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-29 11:36:45 -08:00
Shawn O. Pearce
77ccc5bbd1 Introduce new config option for mmap limit.
Rather than hardcoding the maximum number of bytes which can be
mmapped from pack files we should make this value configurable,
allowing the end user to increase or decrease this limit on a
per-repository basis depending on the size of the repository
and the capabilities of their operating system.

In general users should not need to manually tune such a low-level
setting within the core code, but being able to artifically limit
the number of bytes which we can mmap at once from pack files will
make it easier to craft test cases for the new mmap sliding window
implementation.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-29 11:36:44 -08:00
Junio C Hamano
d2c11a38c4 UTF-8: introduce i18n.logoutputencoding.
It is plausible for somebody to want to view the commit log in a
different encoding from i18n.commitencoding -- the project's
policy may be UTF-8 and the user may be using a commit message
hook to run iconv to conform to that policy (and either not have
i18n.commitencoding to default to UTF-8 or have it explicitly
set to UTF-8).  Even then, Latin-1 may be more convenient for
the usual pager and the terminal the user uses.

The new variable i18n.logoutputencoding is used in preference to
i18n.commitencoding to decide what encoding to recode the log
output in when git-log and friends formats the commit log message.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-27 16:41:33 -08:00
Junio C Hamano
aa1cef54a2 Merge branch 'jc/clone'
* jc/clone:
  Move "no merge candidate" warning into git-pull
  Use preprocessor constants for environment variable names.
  Do not create $GIT_DIR/remotes/ directory anymore.
  Introduce GIT_TEMPLATE_DIR
  Revert "fix testsuite: make sure they use templates freshly built from the source"
  fix testsuite: make sure they use templates freshly built from the source
  git-clone: lose the traditional 'no-separate-remote' layout
  git-clone: lose the artificial "first" fetch refspec
  git-pull: refuse default merge without branch.*.merge
  git-clone: use wildcard specification for tracking branches
2006-12-20 13:56:14 -08:00
Junio C Hamano
85023577a8 simplify inclusion of system header files.
This is a mechanical clean-up of the way *.c files include
system header files.

 (1) sources under compat/, platform sha-1 implementations, and
     xdelta code are exempt from the following rules;

 (2) the first #include must be "git-compat-util.h" or one of
     our own header file that includes it first (e.g. config.h,
     builtin.h, pkt-line.h);

 (3) system headers that are included in "git-compat-util.h"
     need not be included in individual C source files.

 (4) "git-compat-util.h" does not have to include subsystem
     specific header files (e.g. expat.h).

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20 09:51:35 -08:00
Junio C Hamano
fc1905bb93 config_rename_section: fix FILE* leak
Noticed by SungHyun Nam.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19 22:30:59 -08:00
Junio C Hamano
d4ebc36c5e Use preprocessor constants for environment variable names.
We broke the discipline Linus set up to allow compiler help us
avoid typos in environment names in the early days of git over
time.  This defines a handful preprocessor constants for
environment variable names used in relatively core parts of the
system.

I've left out variable names specific to subsystems such as HTTP
and SSL as I do not think they are big problems.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19 01:51:51 -08:00
Johannes Schindelin
0667fcfb62 add a function to rename sections in the config
Given a config like this:

	# A config
	[very.interesting.section]
		not

The command

	$ git repo-config --rename-section very.interesting.section bla.1

will lead to this config:

	# A config
	[bla "1"]
		not

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-16 13:28:20 -08:00
Andy Parkins
a159ca0cb7 Allow subcommand.color and color.subcommand color configuration
While adding colour to the branch command it was pointed out that a
config option like "branch.color" conflicts with the pre-existing
"branch.something" namespace used for specifying default merge urls and
branches.  The suggested solution was to flip the order of the
components to "color.branch", which I did for colourising branch.

This patch does the same thing for
  - git-log (color.diff)
  - git-status (color.status)
  - git-diff (color.diff)
  - pager (color.pager)

I haven't removed the old config options; but they should probably be
deprecated and eventually removed to prevent future namespace
collisions.  I've done this deprecation by changing the documentation
for the config file to match the new names; and adding the "color.XXX"
options to contrib/completion/git-completion.bash.

Unfortunately git-svn reads "diff.color" and "pager.color"; which I
don't like to change unilaterally.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-13 01:47:36 -08:00
Linus Torvalds
38c5afa87e Allow '-' in config variable names
I need this in order to allow aliases of the same form as "ls-tree",
"rev-parse" etc, so that I can use

	[alias]
		my-cat=--paginate cat-file -p

to add a "git my-cat" command.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-10-30 19:39:12 -08:00
Shawn Pearce
9befac470b Replace uses of strdup with xstrdup.
Like xmalloc and xrealloc xstrdup dies with a useful message if
the native strdup() implementation returns NULL rather than a
valid pointer.

I just tried to use xstrdup in new code and found it to be missing.
However I expected it to be present as xmalloc and xrealloc are
already commonly used throughout the code.

[jc: removed the part that deals with last_XXX, which I am
 finding more and more dubious these days.]

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-02 03:24:37 -07:00
Jonas Fonseca
2d7320d0b0 Use xmalloc instead of malloc
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-31 16:24:39 -07:00
Junio C Hamano
4cac42b132 free(NULL) is perfectly valid.
Jonas noticed some places say "if (X) free(X)" which is totally
unnecessary.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-27 21:19:39 -07:00
Matthias Lederhofer
aa086eb813 pager: config variable pager.color
enable/disable colored output when the pager is in use

Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-31 15:32:24 -07:00
Linus Torvalds
93821bd97a sha1_file: add the ability to parse objects in "pack file format"
The pack-file format is slightly different from the traditional git
object format, in that it has a much denser binary header encoding.
The traditional format uses an ASCII string with type and length
information, which is somewhat wasteful.

A new object format starts with uncompressed binary header
followed by compressed payload -- this will allow us later to
copy the payload straight to packfiles.

Obviously they cannot be read by older versions of git, so for
now new object files are created with the traditional format.
core.legacyheaders configuration item, when set to false makes
the code write in new format for people to experiment with.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-13 23:11:56 -07:00
Junio C Hamano
624314fda7 boolean: accept yes and no as well
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-03 18:48:23 -07:00
Joachim B Haga
12f6c308d5 Make zlib compression level configurable, and change default.
With the change in default, "git add ." on kernel dir is about
twice as fast as before, with only minimal (0.5%) change in
object size. The speed difference is even more noticeable
when committing large files, which is now up to 8 times faster.

The configurability is through setting core.compression = [-1..9]
which maps to the zlib constants; -1 is the default, 0 is no
compression, and 1..9 are various speed/size tradeoffs, 9
being slowest.

Signed-off-by: Joachim B Haga (cjhaga@fys.uio.no)
Acked-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-03 13:55:11 -07:00
Peter Eriksen
817151e61a Rename safe_strncpy() to strlcpy().
This cleans up the use of safe_strncpy() even more.  Since it has the
same semantics as strlcpy() use this name instead.  Also move the
definition from inside path.c to its own file compat/strlcpy.c, and use
it conditionally at compile time, since some platforms already has
strlcpy().  It's included in the same way as compat/setenv.c.

Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-24 23:16:25 -07:00
Johannes Schindelin
e33d0611c0 git_config: access() returns 0 on success, not > 0
Another late-night bug. Sorry again.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-20 01:21:53 -07:00
Johannes Schindelin
5f1a63e0ef Read configuration also from $HOME/.gitconfig
This patch is based on Pasky's, with three notable differences:

- I did not yet update the documentation
- I named it .gitconfig, not .gitrc
- git-repo-config does not barf when a unique key is overridden locally

The last means that if you have something like

	[alias]
		l = log --stat -M

in ~/.gitconfig, and

	[alias]
		l = log --stat -M next..

in $GIT_DIR/config, then

	git-repo-config alias.l

returns only one value, namely the value from $GIT_DIR/config.

If you set the environment variable GIT_CONFIG, $HOME/.gitconfig is not
read, and neither $GIT_DIR/config, but $GIT_CONFIG instead.

If you set GIT_CONFIG_LOCAL instead, it is interpreted instead of
$GIT_DIR/config, but $HOME/.gitconfig is still read.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-19 17:53:13 -07:00
Johannes Schindelin
9c3796fc04 Fix setting config variables with an alternative GIT_CONFIG
When setting a config variable, git_config_set() ignored the variables
GIT_CONFIG and GIT_CONFIG_LOCAL. Now, when GIT_CONFIG_LOCAL is set, it
will write to that file. If not, GIT_CONFIG is checked, and only as a
fallback, the change is written to $GIT_DIR/config.

Add a test for it, and also future-proof the test for the upcoming
$HOME/.gitconfig support.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-19 17:30:34 -07:00
Petr Baudis
7f29f7a95c Support for extracting configuration from different files
Add $GIT_CONFIG environment variable whose content is used instead
of .git/config if set. Also add $GIT_CONFIG_LOCAL as a
forward-compatibility cue for whenever we will finally come to support]
global configuration files (properly).

Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-18 21:19:07 -07:00
Peter Eriksen
bfbd0bb6ec Implement safe_strncpy() as strlcpy() and use it more.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-16 22:45:12 -07:00
Junio C Hamano
138086a725 shared repository - add a few missing calls to adjust_shared_perm().
There were a few calls to adjust_shared_perm() that were
missing:

 - init-db creates refs, refs/heads, and refs/tags before
   reading from templates that could specify sharedrepository in
   the config file;

 - updating config file created it under user's umask without
   adjusting;

 - updating refs created it under user's umask without
   adjusting;

 - switching branches created .git/HEAD under user's umask
   without adjusting.

This moves adjust_shared_perm() from sha1_file.c to path.c,
since a few SIMPLE_PROGRAM need to call repository configuration
functions which in turn need to call adjust_shared_perm().
sha1_file.c needs to link with SHA1 computation library which
is usually not linked to SIMPLE_PROGRAM.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-09 22:15:50 -07:00
Shawn Pearce
6de08ae688 Log ref updates to logs/refs/<ref>
If config parameter core.logAllRefUpdates is true or the log
file already exists then append a line to ".git/logs/refs/<ref>"
whenever git-update-ref <ref> is executed.  Each log line contains
the following information:

  oldsha1 <SP> newsha1 <SP> committer <LF>

where committer is the current user, date, time and timezone in
the standard GIT ident format.  If the caller is unable to append
to the log file then git-update-ref will fail without updating <ref>.

An optional message may be included in the log line with the -m flag.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-17 17:36:36 -07:00
Linus Torvalds
d14f776402 git config syntax updates
This updates the hierarchical section name syntax to

	[section<space>+"<randomstring>"]

where the only rule for "randomstring" is that it can't contain a newline,
and if you really want to insert a double-quote, you do it with \".

It turns that into the section name "secion.randomstring".  The
"section" part is still case insensitive, but the "randomstring"
part is case sensitive.

So you could use this for things like

	[email "torvalds@osdl.org"]
		name = Linus Torvalds

if you wanted to do the "email->name" conversion as part of the config
file format (I'm not claiming that is sensible, I'm just giving it as an
insane example). That would show up as the association

	email.torvalds@osdl.org.name -> Linus Torvalds

which is easy to parse (the "." in the email _looks_ ambiguous, but it
isn't: you know that there will always be a single key-name, so you find
the key name with "strrchr(name, '.')" and things are entirely
unambiguous).

Repo-config is updated to be able to parse the new format, and also
write things out in the new format.

[jc: rolled two patches from Linus and one fix-up from Sean into one,
 with additional adjustments for t/t1300 test to check the case
 insensitiveness of section base and variable and case sensitiveness
 of the extended section part.  Then stripped some part off to make
 the result applicable to the stale 1.3.X series that does not have
 recent enhancements. ]

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-13 14:00:16 -07:00
sean
bdf0ef0824 Another config file parsing fix.
If the variable we need to store should go into a section
that currently only has a single variable (not matching
the one we're trying to insert), we will already be into
the next section before we notice we've bypassed the correct
location to insert the variable.

To handle this case we store the current location as soon
as we find a variable matching the section of our new
variable.

This breakage was brought up by Linus.

Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-13 14:00:16 -07:00
Junio C Hamano
f8ba655ee4 Fix repo-config set-multivar error return path.
This hopefully fixes the problem an earlier commit 5d8ee9ceb attemted
to fix.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-07 21:27:30 -07:00
Pavel Roskin
5d8ee9ceb8 Release config lock if the regex is invalid
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-07 15:31:06 -07:00
Junio C Hamano
e388c73825 core.prefersymlinkrefs: use symlinks for .git/HEAD
When inspecting a project whose build infrastructure used to
assume that .git/HEAD is a symlink ref, core.prefersymlinkrefs
in the config file of such a project would help to bisect its
history.

Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from 9f0bb90d16 commit)
2006-05-05 14:37:08 -07:00
Johannes Schindelin
7ebdba6142 repo-config: trim white-space before comment
Earlier, calling

	git-repo-config core.hello

on a .git/config like this:

	[core]
		hello = world ; a comment

would yield "world " (i.e. with a trailing space).

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from c1aee1fd8d commit)
2006-05-05 14:34:47 -07:00
sean
93ddef3e2d Fix for config file section parsing.
Currently, if the target key has a section that matches
the initial substring of another section we mistakenly
believe we've found the correct section.  To avoid this
problem, ensure that the section lengths are identical
before comparison.

Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 14:33:58 -07:00
Petr Baudis
1ab661ddb7 Document the configuration file
This patch adds a Documentation/config.txt file included by git-repo-config
and currently aggregating hopefully all the available git plumbing / core
porcelain configuration variables, as well as briefly describing the format.

It also updates an outdated bit of the example in git-repo-config(1).

Signed-off-by: Petr Baudis <pasky@suse.cz>
2006-04-24 22:26:37 -07:00
Serge E. Hallyn
dafc88b136 cleanups: prevent leak of two strduped strings in config.c
Config_filename and lockfile are strduped and then leaked in
git_config_set_multivar.

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-17 15:06:37 -07:00
Junio C Hamano
2f8acdb38e core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-20 23:34:17 -08:00
Junio C Hamano
5f73076c1a "Assume unchanged" git
This adds "assume unchanged" logic, started by this message in the list
discussion recently:

	<Pine.LNX.4.64.0601311807470.7301@g5.osdl.org>

This is a workaround for filesystems that do not have lstat()
that is quick enough for the index mechanism to take advantage
of.  On the paths marked as "assumed to be unchanged", the user
needs to explicitly use update-index to register the object name
to be in the next commit.

You can use two new options to update-index to set and reset the
CE_VALID bit:

	git-update-index --assume-unchanged path...
	git-update-index --no-assume-unchanged path...

These forms manipulate only the CE_VALID bit; it does not change
the object name recorded in the index file.  Nor they add a new
entry to the index.

When the configuration variable "core.ignorestat = true" is set,
the index entries are marked with CE_VALID bit automatically
after:

 - update-index to explicitly register the current object name to the
   index file.

 - when update-index --refresh finds the path to be up-to-date.

 - when tools like read-tree -u and apply --index update the working
   tree file and register the current object name to the index file.

The flag is dropped upon read-tree that does not check out the index
entry.  This happens regardless of the core.ignorestat settings.

Index entries marked with CE_VALID bit are assumed to be
unchanged most of the time.  However, there are cases that
CE_VALID bit is ignored for the sake of safety and usability:

 - while "git-read-tree -m" or git-apply need to make sure
   that the paths involved in the merge do not have local
   modifications.  This sacrifices performance for safety.

 - when git-checkout-index -f -q -u -a tries to see if it needs
   to checkout the paths.  Otherwise you can never check
   anything out ;-).

 - when git-update-index --really-refresh (a new flag) tries to
   see if the index entry is up to date.  You can start with
   everything marked as CE_VALID and run this once to drop
   CE_VALID bit for paths that are modified.

Most notably, "update-index --refresh" honours CE_VALID and does
not actively stat, so after you modified a file in the working
tree, update-index --refresh would not notice until you tell the
index about it with "git-update-index path" or "git-update-index
--no-assume-unchanged path".

This version is not expected to be perfect.  I think diff
between index and/or tree and working files may need some
adjustment, and there probably needs other cases we should
automatically unmark paths that are marked to be CE_VALID.

But the basics seem to work, and ready to be tested by people
who asked for this feature.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-08 21:54:42 -08:00
Alex Riesen
88fb958baa use result of open(2) to check for presence
Not that the stat against open race would matter much in this context,
but that simplifies
the code a bit. Also some diagnostics added (why the open failed)

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-05 17:22:51 -08:00
Alex Riesen
7246ed438c \n usage in stderr output
fprintf and die sometimes have missing/excessive "\n" in their arguments,
correct the strings where I think it would be appropriate.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-21 23:09:40 -08:00
Junio C Hamano
53e7181cd9 config.c: remove unnecessary header in minimum configuration file.
It is just silly to start the file called "config" with a
comment that says "This is the config file."

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-05 12:58:53 -08:00
Junio C Hamano
0dccc7dcee config.c: constness tightening to avoid compilation warning.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-28 01:46:15 -08:00
Junio C Hamano
4e72dcec89 Introduce i18n.commitencoding.
This is to hold what the project-local rule as to the
charset/encoding for the commit log message is.  Lack of it
defaults to utf-8.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-27 16:09:40 -08:00
Junio C Hamano
4f629539cd init-db: check template and repository format.
This makes init-db repository version aware.

It checks if an existing config file says the repository being
reinitialized is of a wrong version and aborts before doing
further harm.

When copying the templates, it makes sure the they are of the
right repository format version.  Otherwise the templates are
ignored with an warning message.

It copies the templates before creating the HEAD, and if the
config file is copied from the template directory, reads it,
primarily to pick up the value of core.symrefsonly.

It changes the way the result of the filemode reliability test
is written to the configuration file using git_config_set().
The test is done even if the config file was copied from the
templates.

And finally, our own repository format version is written to the
config file.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-27 01:32:59 -08:00
Junio C Hamano
3a2f2bb354 config.c: avoid shadowing global.
This is purely cosmetic, but avoid shadowing "FILE *config_file"
global in git_config_set_multivar() function.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-25 11:10:49 -08:00
Junio C Hamano
9ce392f482 Move diff.renamelimit out of default configuration.
Otherwise we would end up linking all the unneeded stuff into git-daemon
only to link with git_default_config.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21 23:00:50 -08:00
Johannes Schindelin
b17e659dd4 Allow hierarchical section names
A .git/config like follows becomes valid with this patch:

	[remote.junio]
		url = git://git.kernel.org/pub/scm/git/git.git
		pull = master:junio todo:todo +pu:pu

	[remote.ibook]
		url = ibook:git/
		pull = master:ibook
		push = master:quetzal

(This patch only does the ini file thing, git-fetch and friends still
ignore these values).

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21 14:04:28 -08:00
Johannes Schindelin
3dd94e3b2e git-config-set: Properly terminate strings with '\0'
When a lowercase version of the key was generated, it was not
terminated. Strangely enough, it worked on Linux and macosx anyway.
Just cygwin barfed.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-21 14:04:22 -08:00
Johannes Schindelin
f98d863d21 git-config-set: support selecting values by non-matching regex
Extend the regex syntax of value_regex so that prepending an exclamation
mark means non-match:

	[core]
		quetzal = "Dodo" for Brainf*ck
		quetzal = "T. Rex" for Malbolge
		quetzal = "cat"

You can match the third line with

	git-config-set --get quetzal '! for '

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-20 10:53:06 -08:00
Johannes Schindelin
4ddba79db7 git-config-set: add more options
... namely

--replace-all, to replace any amount of matching lines, not just 0 or 1,
--get, to get the value of one key,
--get-all, the multivar version of --get, and
--unset-all, which deletes all matching lines from .git/config

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19 23:15:07 -08:00
Johannes Schindelin
10bea152a3 Add functions git_config_set() and git_config_set_multivar()
The function git_config_set() does exactly what you think it does.
Given a key (in the form "core.filemode") and a value, it sets the
key to the value. Example:

	git_config_set("core.filemode", "true");

The function git_config_set_multivar() is meant for setting variables which
can have several values for the same key. Example:

	[diff]
		twohead = resolve
		twohead = recarsive

the typo in the second line can be replaced by

	git_config_set_multivar("diff.twohead", "recursive", "^recar");

The third argument of the function is a POSIX extended regex which has to
match the value. If there is no key/value pair with a matching value, a new
key/value pair is added.

These commands are also capable of unsetting (deleting) entries:

	git_config_set_multivar("diff.twohead", NULL, "sol");

will delete the entry

		twohead = resolve

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-19 20:47:29 -08:00
Junio C Hamano
3299c6f6a8 diff: make default rename detection limit configurable.
A while ago, a rename-detection limit logic was implemented as a
response to this thread:

	http://marc.theaimsgroup.com/?l=git&m=112413080630175

where gitweb was found to be using a lot of time and memory to
detect renames on huge commits.  git-diff family takes -l<num>
flag, and if the number of paths that are rename destination
candidates (i.e. new paths with -M, or modified paths with -C)
are larger than that number, skips rename/copy detection even
when -M or -C is specified on the command line.

This commit makes the rename detection limit easier to use.  You
can have:

	[diff]
		renamelimit = 30

in your .git/config file to specify the default rename detection
limit.  You can override this from the command line; giving 0
means 'unlimited':

	git diff -M -l0

We might want to change the default behaviour, when you do not
have the configuration, to limit it to say 20 paths or so.  This
would also help the diffstat generation after a big 'git pull'.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-15 15:08:27 -08:00
Johannes Schindelin
f8348be3be Add config variable core.symrefsonly
This allows you to force git to avoid symlinks for refs. Just add
something like

	[core]
		symrefsonly = true

to .git/config.

Don´t forget to "git checkout your_branch", or it does not do anything...

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-15 11:42:29 -08:00