Commit Graph

5 Commits

Author SHA1 Message Date
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>
2008-08-01 22:41:07 -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