1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-10-30 22:07:53 +01:00
Commit graph

58 commits

Author SHA1 Message Date
Frank Lichtenheld
32d1776b13 init: Do not segfault on big GIT_TEMPLATE_DIR environment variable
Signed-off-by: Frank Lichtenheld <flichtenheld@astaro.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-18 13:06:40 -07:00
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>
2008-10-08 07:18:44 -07:00
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>
2008-07-27 23:14:03 -07:00
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>
2008-07-11 21:13:16 -07:00
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>
2008-05-28 18:31:19 -07:00
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>
2008-03-25 00:34:05 -07:00
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>
2007-12-04 14:48:45 -08:00
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>
2007-08-27 22:36:43 -07:00