kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Junio C Hamano	acb70149bc	repo-config: fix printing of bool When a bool variable appears without any value, it means true. However, replacing the NULL value with an empty string, an earlier commit `f067a13745` broke show-config. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Johannes Schindelin	92a28be0ce	repo-config: Fix late-night bug This bug was hidden by the "future-proofing" of the test. Sigh. When neither GIT_CONFIG nor GIT_CONFIG_LOCAL is set, do not use NULL, but $GIT_DIR/config. Instead of using $GIT_DIR/config when only GIT_CONFIG_LOCAL is set. Sorry. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
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>	19 years ago
Linus Torvalds	4d599e6bb4	bogus "fatal: Not a git repository" I was just testing that "git ls-remote" change by Junio, and when you're not in a git repository, it gives this totally bogus warning. The _target_ obviously has to be a git repository, but there's no reason why you'd have to be in a local git repo when doing an ls-remote. The reason is commit `73136b2e8a` by Dscho: it adds calls to git-repo-config in git-parse-remote.sh to get the remote shorthands etc. Now, either we should just hide and ignore the error from git-repo-config (probably bad, because some errors _are_ valid - like git-repo-config failing due to bad syntax in the config file), or we should just make git-repo-config quietly handle the case of not being in a git repository. This does the latter: just quietly accepting (and doing nothing - trying to set a value will result in the lock-file failing) our lot in life sounds better than dying with a bogus error message. Signed-off-by: Linus Torvalds <torvalds@osdl.org> Acked-By: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
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>	19 years ago
Johannes Schindelin	8f5ff31f8e	repo-config: deconvolute logics It was rightly noticed that the logic is quite convoluted. Fix that. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	e098c6f82a	repo-config: readability fixups. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Johannes Schindelin	2fa9a0fb31	repo-config: support --get-regexp With --get-regexp, output all key/value pairs where the key matches a regexp. Example: git-repo-config --get-regexp remote.*.url will output something like remote.junio.url git://git.kernel.org/pub/scm/git/git.git remote.gitk.url git://git.kernel.org/pub/scm/gitk/gitk.git Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Johannes Schindelin	cfa24e184a	repo-config: fix segfault with no argument. An earlier addition of --list feature was carelessly done and caused an invalid access to argv[1] when it was not given. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Petr Baudis	de791f15a1	git-repo-config --list support This adds git-repo-config --list (or git-repo-config -l) support, similar to what git-var -l does now (to be phased out so that we have a single sane interface to the config file instead of fragmented and confused API). Signed-off-by: Petr Baudis <pasky@suse.cz>	19 years ago
Jonas Fonseca	f067a13745	repo-config: give value_ a sane default so regexec won't segfault Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Petr Baudis	7162dff3dd	Add support for explicit type specifiers when calling git-repo-config Currently, git-repo-config will just return the raw value of option as specified in the config file; this makes things difficult for scripts calling it, especially if the value is supposed to be boolean. This patch makes it possible to ask git-repo-config to check if the option is of the given type (int or bool) and write out the value in its canonical form. If you do not pass --int or --bool, the behaviour stays unchanged and the raw value is emitted. This also incidentally fixes the segfault when option with no value is encountered. [jc: tweaked the option parsing a bit to make it easier to see that the patch does not change anything but the type stuff in the diff output. Also changed to avoid "foo ? : bar" construct. ] Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Amos Waterland	0a15217184	AIX compile fix for repo-config.c AIX 5 has a /usr/include/regex.h containing this code: #ifdef _NO_PROTO extern char regex(); extern char regcmp(); #else /* _NO_PROTO / extern char regex(const char , const char , ...); extern char regcmp(const char , ...); #endif /* _NO_PROTO */ This means that repo-config.c is trying to redefine the `regex' symbol. Here is a simple patch that just uses `regexp' as the symbol name instead. Signed-off-by: Amos Waterland <apw@us.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Johannes Schindelin	ee72aeaf00	Rename git-config-set to git-repo-config ... and adjust all references. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
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>	19 years ago
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>	19 years ago
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>	19 years ago
Johannes Schindelin	1b1e59c508	Add git-config-set, a simple helper for scripts to set config variables This is meant for the end user, who cannot be expected to edit .git/config by hand. Example: git-config-set core.filemode true will set filemode in the section [core] to true, git-config-set --unset core.filemode will remove the entry (failing if it is not there), and git-config-set --unset diff.twohead ^recar will remove the unique entry whose value matches the regex "^recar" (failing if there is no unique such entry). It is just a light wrapper around git_config_set() and git_config_set_multivar(). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago

15 Commits (16da134b1f9b0fbd1d328999875d34d02e5470b4)