kernel/git - git - PowerEL Git System

Author	SHA1	Message	Date
Deskin Miller	0a2c7eea41	git init: --bare/--shared overrides system/global config If core.bare or core.sharedRepository are set in /etc/gitconfig or ~/.gitconfig, then 'git init' will read the values when constructing a new config file; reading them, however, will override the values specified on the command line. In the case of --bare, this ends up causing a segfault, without the repository being properly initialised; in the case of --shared, the permissions are set according to the existing config settings, not what was specified on the command line. This fix saves any specified values for --bare and --shared prior to reading existing config settings, and restores them after reading but before writing the new config file. core.bare is ignored in all situations, while core.sharedRepository will only be used if --shared is not specified to git init. Also includes testcases which use a specified global config file override, demonstrating the former failure scenario. Signed-off-by: Deskin Miller <deskinm@umich.edu> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>	16 years ago
Jeff King	d65d2b2fb4	init: handle empty "template" parameter If a user passes "--template=", then our template parameter is blank. Unfortunately, copy_templates() assumes it has at least one character, and does all sorts of bad things like reading from template[-1] and then proceeding to link all of '/' into the .git directory. This patch just checks for that condition in copy_templates and aborts. As a side effect, this means that --template= now has the meaning "don't copy any templates." Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Jeff King	172035f044	init: handle empty "template" parameter If a user passes "--template=", then our template parameter is blank. Unfortunately, copy_templates() assumes it has at least one character, and does all sorts of bad things like reading from template[-1] and then proceeding to link all of '/' into the .git directory. This patch just checks for that condition in copy_templates and aborts. As a side effect, this means that --template= now has the meaning "don't copy any templates." Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Miklos Vajna	b613827318	t0001-init.sh: change confusing directory name using git-init as directory name confused 'make remove-dashes', so just drop the 'git-' prefix. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Luciano Rocha	74d3b23fe3	git-init: accept --bare option It is unfortunate that "git init --bare" does not work and the only reason why "init" did not learn its own "--bare" option is because "git --bare init" already does the job (and as an option to the git 'potty', it is more generic solution). This teaches "git init" its own "--bare" option, so that both "git --bare init" and "git init --bare" works mostly the same way. [jc: rewrote the log message and added test] Signed-off-by: Luciano Rocha <strange@nsk.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Johannes Schindelin	5cc8f37250	init: show "Reinit" message even in an (existing) empty repository Earlier, git-init tested for a valid HEAD ref, but if the repository was empty, there was none. Instead, test for the existence of the file $GIT_DIR/HEAD. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
H.Merijn Brand	5188408057	Do not rely on the exit status of "unset" for unset variables POSIX says that exit status "0" means that "unset" successfully unset the variable. However, it is kind of ambiguous if an environment variable which was not set could be successfully unset. At least the default shell on HP-UX insists on reporting an error in such a case, so just ignore the exit status of "unset". [Dscho: extended the patch to git-submodule.sh, as Junio realized that this is the only other place where we check the exit status of "unset".] Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Junio C Hamano	6adcca3fe8	Fix initialization of a bare repository Here is my attempt to fix this with a minimally intrusive patch. * As "git --bare init" cannot tell if it was called with --bare or just "GIT_DIR=. git init", I added an explicit assignment of is_bare_repository_cfg on the codepath for "git --bare". * GIT_WORK_TREE alone without GIT_DIR does not make any sense, nor GIT_WORK_TREE with an explicit "git --bare". Catch that mistake. It might make sense to move this check to "git.c" side as well, but I tried to shoot for the minimum change for now. * Some scripts, especially from the olden days, rely on traditional GIT_DIR behaviour in "git init". Namely, these are some notable patterns: (create a bare repository) - mkdir some.git && cd some.git && GIT_DIR=. git init - mkdir some.git && cd some.git && git --bare init (create a non-bare repository) - mkdir .git && GIT_DIR=.git git init - mkdir .git && GIT_DIR=`pwd`/.git git init This comes with a new test script and also passes the existing test suite, but there may be cases that are still broken with the current tip of master and this patch does not yet fix. I'd appreciate help in straightening this mess out. Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago