Requires a small change to wrap-for-bin.sh in order to work.
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test for correct permissions after init created a deep directory
must be guarded by POSIXPERM. But testing that the deep dirctory exists
is good even on platforms that do not provide the POSIXPERM prerequiste.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this change, grep fails because it does not find the file
instead of because it does not find the text in the file.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When starting a new repository, I see my students often say
% git init newrepo
and curse git. They could say
% mkdir newrepo; cd newrepo; git init
but allowing it as an obvious short-cut may be nicer.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
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>
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>
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>
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>
