summaryrefslogtreecommitdiff
path: root/config.c
AgeCommit message (Collapse)AuthorFilesLines
2007-06-07War on whitespaceLibravatar Junio C Hamano1-2/+1
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-05-20Merge branch 'dh/pack'Libravatar Junio C Hamano1-1/+17
* dh/pack: Custom compression levels for objects and packs
2007-05-20Merge branch 'np/pack'Libravatar Junio C Hamano1-5/+0
* 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-13git-config: do not forget seeing "a.b.var" means we are out of "a.var" section.Libravatar Junio C Hamano1-4/+24
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-10Custom compression levels for objects and packsLibravatar Dana How1-1/+17
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-10deprecate the new loose object header formatLibravatar Nicolas Pitre1-5/+0
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-04-05Fix renaming branch without config fileLibravatar Geert Bosch1-2/+3
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-03-18Limit the size of the new delta_base_cacheLibravatar Shawn O. Pearce1-0/+5
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-16use xstrdup pleaseLibravatar Shawn O. Pearce1-2/+2
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-08Merge branch 'js/config-rename'Libravatar Junio C Hamano1-24/+36
* js/config-rename: git-config: document --rename-section, provide --remove-section
2007-03-07Cast 64 bit off_t to 32 bit size_tLibravatar Shawn O. Pearce1-13/+15
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-03git-config: document --rename-section, provide --remove-sectionLibravatar Paolo Bonzini1-24/+36
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-02Add core.symlinks to mark filesystems that do not support symbolic links.Libravatar Johannes Sixt1-0/+5
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-02-24Merge branch 'js/etc-config'Libravatar Junio C Hamano1-0/+2
* js/etc-config: Make tests independent of global config files config: read system-wide defaults from /etc/gitconfig
2007-02-22Merge branches 'lt/crlf' and 'jc/apply-config'Libravatar Junio C Hamano1-0/+9
* 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-19config: read system-wide defaults from /etc/gitconfigLibravatar Johannes Schindelin1-0/+2
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-14Make sure packedgitwindowsize is multiple of (pagesize * 2)Libravatar Junio C Hamano1-5/+7
The next patch depends on this. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-02-14Make AutoCRLF ternary variable.Libravatar Linus Torvalds1-0/+4
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-14Lazy man's auto-CRLFLibravatar Linus Torvalds1-0/+5
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-03git-config --rename-section could rename wrong sectionLibravatar Pavel Roskin1-1/+1
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-01-19config_set_multivar(): disallow newlines in keysLibravatar Johannes Schindelin1-0/+5
This will no longer work: $ git repo-config 'key.with newline' some-value Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
2007-01-11Merge branch 'jc/bare'Libravatar Junio C Hamano1-0/+5
* 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-11config-set: check write-in-full returns in set_multivarLibravatar Junio C Hamano1-19/+24
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-08Auto-quote config values in config.c:store_write_pair()Libravatar Brian Gernhardt1-0/+14
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-08short i/o: fix config updates to use write_in_fullLibravatar Andy Whitcroft1-29/+77
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-07Introduce is_bare_repository() and core.bare configuration variableLibravatar Junio C Hamano1-0/+5
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>
2006-12-30Merge branch 'master' into sp/mmapLibravatar Junio C Hamano1-0/+6
* 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-30Teach Git how to parse standard power of 2 suffixes.Libravatar Shawn O. Pearce1-0/+6
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-29Replace mmap with xmmap, better handling MAP_FAILED.Libravatar Shawn O. Pearce1-1/+1
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-29Ensure core.packedGitWindowSize cannot be less than 2 pages.Libravatar Shawn O. Pearce1-2/+2
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-29Fully activate the sliding window pack access.Libravatar Shawn O. Pearce1-0/+10
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-29Introduce new config option for mmap limit.Libravatar Shawn O. Pearce1-0/+5
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-27UTF-8: introduce i18n.logoutputencoding.Libravatar Junio C Hamano1-1/+7
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-20Merge branch 'jc/clone'Libravatar Junio C Hamano1-6/+6
* 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-20simplify inclusion of system header files.Libravatar Junio C Hamano1-1/+0
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-19config_rename_section: fix FILE* leakLibravatar Junio C Hamano1-6/+13
Noticed by SungHyun Nam. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-19Use preprocessor constants for environment variable names.Libravatar Junio C Hamano1-6/+6
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-16add a function to rename sections in the configLibravatar Johannes Schindelin1-0/+64
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-13Allow subcommand.color and color.subcommand color configurationLibravatar Andy Parkins1-1/+1
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-10-30Allow '-' in config variable namesLibravatar Linus Torvalds1-3/+8
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-09-02Replace uses of strdup with xstrdup.Libravatar Shawn Pearce1-4/+4
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-08-31Use xmalloc instead of mallocLibravatar Jonas Fonseca1-2/+2
Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-27free(NULL) is perfectly valid.Libravatar Junio C Hamano1-4/+2
Jonas noticed some places say "if (X) free(X)" which is totally unnecessary. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-31pager: config variable pager.colorLibravatar Matthias Lederhofer1-0/+5
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-13sha1_file: add the ability to parse objects in "pack file format"Libravatar Linus Torvalds1-0/+5
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-03boolean: accept yes and no as wellLibravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-03Make zlib compression level configurable, and change default.Libravatar Joachim B Haga1-0/+10
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-06-24Rename safe_strncpy() to strlcpy().Libravatar Peter Eriksen1-3/+3
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-20git_config: access() returns 0 on success, not > 0Libravatar Johannes Schindelin1-1/+1
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-19Read configuration also from $HOME/.gitconfigLibravatar Johannes Schindelin1-9/+25
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>