- 16 2月, 2008 4 次提交
-
-
由 Christian Couder 提交于
Also use "git_config_string" to simplify "config.c" code where "excludes_file" is set. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
Also use "git_config_string" to simplify "config.c" code where "editor_program" is set. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
Also use "git_config_string" to simplify "config.c" code where "pager_program" is set. Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Christian Couder 提交于
In many places we just check if a value from the config file is not NULL, then we duplicate it and return 0. This patch introduces the new 'git_config_string' function to do that. This function is also used to refactor some code in 'config.c'. Refactoring other files is left for other patches. Also not all the code in "config.c" is refactored, because the function takes a "const char **" as its first parameter, but in many places a "char *" is used instead of a "const char *". (And C does not allow using a "char **" instead of a "const char **" without a warning.) Signed-off-by: NChristian Couder <chriscool@tuxfamily.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 12 2月, 2008 2 次提交
-
-
由 Junio C Hamano 提交于
user.{name,email}, core.{pager,editor,excludesfile,whitespace} and i18n.{commit,logoutput}encoding all expect string values. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
This is used to report misconfigured configuration file that does not give any value to a non-boolean variable, e.g. [section] var It is perfectly fine to say it if the section.var is a boolean (it means true), but if a variable expects a string value it should be flagged as a configuration error. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 2月, 2008 1 次提交
-
-
由 Frank Lichtenheld 提交于
find_beginning_of_line didn't take into account that the previous line might have ended with \ in which case it shouldn't stop but continue its search. Signed-off-by: NFrank Lichtenheld <frank@lichtenheld.de> Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 2月, 2008 1 次提交
-
-
由 Jeff King 提交于
The GIT_CONFIG_NOGLOBAL and GIT_CONFIG_NOSYSTEM environment variables are magic undocumented switches that can be used to ensure a totally clean environment. This is necessary for running reliable tests, since those config files may contain settings that change the outcome of tests. Signed-off-by: NJeff King <peff@peff.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 2月, 2008 1 次提交
-
-
由 Johannes Sixt 提交于
When DEFAULT_GIT_TEMPLATE_DIR is specified as a relative path, init-db made it relative to exec_path using prefix_path(), which is wrong. prefix_path() is about a file inside the work tree. There was a similar misuse in config.c that takes relative ETC_GITCONFIG path. Noticed by Junio C Hamano. We concatenate the paths manually. (prefix_filename() won't do because it expects a prefix with a trailing '/'.) Signed-off-by: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 04 2月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
When DEFAULT_GIT_TEMPLATE_DIR is specified as a relative path, init-db made it relative to exec_path using prefix_path(), which is wrong. prefix_path() is about a file inside the work tree. There was a similar misuse in config.c that takes relative ETC_GITCONFIG path. A convenience function prefix_filename() can concatenate two paths to form a path that points at somewhere outside the work tree. Use it in these codepaths instead. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 1月, 2008 1 次提交
-
-
由 Brandon Casey 提交于
Remove remaining double close(2)'s. i.e. close() before commit_locked_index() or commit_lock_file(). Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 1月, 2008 1 次提交
-
-
由 Jeff King 提交于
The config parsing routines use the static global 'config_file' to store the FILE* pointing to the current config file being parsed. The function get_next_char() automatically converts an EOF on this file to a newline for the convenience of its callers, and it sets config_file to NULL to indicate that EOF was reached. This throws away useful information, though, since some routines want to call ftell on 'config_file' to find out exactly _where_ the routine ended. In the case of a key ending at EOF boundary, we ended up segfaulting in some cases (changing that key or adding another key in its section), or failing to provide the necessary newline (adding a new section). This patch adds a new flag to indicate EOF and uses that instead of setting config_file to NULL. It also makes sure to add newlines where necessary for truncated input. All three included tests fail without the patch. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 27 12月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 12月, 2007 1 次提交
-
-
由 Kristian Høgsberg 提交于
Avoids horrible 1-byte write(2) calls and cleans up the logic a bit. Signed-off-by: NKristian Høgsberg <krh@redhat.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 09 12月, 2007 1 次提交
-
-
由 Jim Meyering 提交于
Signed-off-by: NJim Meyering <meyering@redhat.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 06 12月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 17 11月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 15 11月, 2007 3 次提交
-
-
由 Johannes Sixt 提交于
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: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Johannes Sixt 提交于
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: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 03 11月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 27 7月, 2007 1 次提交
-
-
由 Bradford C. Smith 提交于
Changed git_commit_set_multivar() to use the routines provided by lockfile.c to reduce code duplication and ensure consistent behavior. Signed-off-by: NBradford C. Smith <bradford.carl.smith@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 22 7月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
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: NJohannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 13 7月, 2007 1 次提交
-
-
由 Brian Downing 提交于
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: NBrian Downing <bdowning@lavos.net> Acked-by: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 05 7月, 2007 1 次提交
-
-
由 Brian Gernhardt 提交于
This adds a configuration variable that performs the same function as, but is overridden by, GIT_PAGER. Signed-off-by: NBrian Gernhardt <benji@silverinsanity.com> Acked-by: NJohannes E. Schindelin <johannes.schindelin@gmx.de> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 25 6月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 13 6月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 6月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <gitster@pobox.com>
-
- 13 5月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
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: NJunio C Hamano <junkio@cox.net>
-
- 11 5月, 2007 2 次提交
-
-
由 Dana How 提交于
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: NDana L. How <danahow@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Nicolas Pitre 提交于
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: NNicolas Pitre <nico@cam.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 06 4月, 2007 1 次提交
-
-
由 Geert Bosch 提交于
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: NGeert Bosch <bosch@gnat.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 3月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 3月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
We generally prefer xstrdup to just plain strdup. Make it so. Signed-off-by: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 08 3月, 2007 1 次提交
-
-
由 Shawn O. Pearce 提交于
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: NShawn O. Pearce <spearce@spearce.org> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 04 3月, 2007 1 次提交
-
-
由 Paolo Bonzini 提交于
This patch documents the previously undocumented option --rename-section and adds a new option to zap an entire section. Signed-off-by: NPaolo Bonzini <bonzini@gnu.org> Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 03 3月, 2007 1 次提交
-
-
由 Johannes Sixt 提交于
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: NJohannes Sixt <johannes.sixt@telecom.at> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 20 2月, 2007 1 次提交
-
-
由 Johannes Schindelin 提交于
The settings in /etc/gitconfig can be overridden in ~/.gitconfig, which in turn can be overridden in .git/config. Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 15 2月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
The next patch depends on this. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-