summaryrefslogtreecommitdiff
path: root/config.c
AgeCommit message (Collapse)AuthorFilesLines
2008-02-15Add "const" qualifier to "char *excludes_file".Libravatar Christian Couder1-6/+2
Also use "git_config_string" to simplify "config.c" code where "excludes_file" is set. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-15Add "const" qualifier to "char *editor_program".Libravatar Christian Couder1-6/+2
Also use "git_config_string" to simplify "config.c" code where "editor_program" is set. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-15Add "const" qualifier to "char *pager_program".Libravatar Christian Couder1-6/+2
Also use "git_config_string" to simplify "config.c" code where "pager_program" is set. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-15config: add 'git_config_string' to refactor string config variables.Libravatar Christian Couder1-13/+12
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: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-11config.c: guard config parser from value=NULLLibravatar Junio C Hamano1-1/+15
user.{name,email}, core.{pager,editor,excludesfile,whitespace} and i18n.{commit,logoutput}encoding all expect string values. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-11Add config_error_nonbool() helper functionLibravatar Junio C Hamano1-0/+9
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: Junio C Hamano <gitster@pobox.com>
2008-02-10config: Fix --unset for continuation linesLibravatar Frank Lichtenheld1-0/+5
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: Frank Lichtenheld <frank@lichtenheld.de> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-16Improve use of lockfile APILibravatar Brandon Casey1-6/+2
Remove remaining double close(2)'s. i.e. close() before commit_locked_index() or commit_lock_file(). Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-01-02config: handle lack of newline at end of file betterLibravatar Jeff King1-5/+9
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: Junio C Hamano <gitster@pobox.com>
2007-12-26Improve error messages when int/long cannot be parsed from configLibravatar Shawn O. Pearce1-10/+21
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-14Use a strbuf for building up section header and key/value pair strings.Libravatar Kristian Høgsberg1-53/+38
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-09Merge branch 'jc/spht'Libravatar Junio C Hamano1-0/+5
* 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-09Merge branch 'maint'Libravatar Junio C Hamano1-2/+8
* maint: config.c:store_write_pair(): don't read the byte before a malloc'd buffer.
2007-12-08config.c:store_write_pair(): don't read the byte before a malloc'd buffer.Libravatar Jim Meyering1-2/+8
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-06Use gitattributes to define per-path whitespace ruleLibravatar Junio C Hamano1-49/+1
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-11-16core.excludesfile clean-upLibravatar Junio C Hamano1-0/+7
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-14Allow ETC_GITCONFIG to be a relative path.Libravatar Johannes Sixt1-1/+12
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-14Introduce git_etc_gitconfig() that encapsulates access of ETC_GITCONFIG.Libravatar Johannes Sixt1-2/+7
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-14core.excludesfile clean-upLibravatar Junio C Hamano1-0/+7
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-02git-diff: complain about >=8 consecutive spaces in initial indentLibravatar Junio C Hamano1-0/+1
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-02War on whitespace: first, a bit of retreat.Libravatar Junio C Hamano1-0/+52
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-08-10Merge branch 'cr/tag'Libravatar Junio C Hamano1-0/+5
* 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-07-27use lockfile.c routines in git_commit_set_multivar()Libravatar Bradford C. Smith1-12/+18
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-21launch_editor(): Heed GIT_EDITOR and core.editor settingsLibravatar Johannes Schindelin1-0/+5
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-12Add functions for parsing integers with size suffixesLibravatar Brian Downing1-12/+46
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-04Add core.pager config variable.Libravatar Brian Gernhardt1-0/+5
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-06-24Add core.quotepath configuration variable.Libravatar Junio C Hamano1-0/+5
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-13-Wold-style-definition fixLibravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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