Commit graph

58 commits

Author SHA1 Message Date
René Scharfe bed67874e2 t0001: skip test with restrictive permissions if getpwd(3) respects them
The sub-test "init in long base path" in t0001 checks the ability to
handle long base paths with restrictive permissions (--x).  On OpenBSD
getcwd(3) fails in that case even for short paths.  Check the two
aspects separately by trying to use a long base path both with and
without execute-only permissions.  Only attempt the former if we know
that getcwd(3) doesn't care.

Original-patch-by: David Coppa <dcoppa@openbsd.org>
Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: René Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-07 10:35:18 -07:00
René Scharfe a54e938e5b strbuf: support long paths w/o read rights in strbuf_getcwd() on FreeBSD
FreeBSD implements getcwd(3) as a syscall, but falls back to a version
based on readdir(3) if it fails for some reason.  The latter requires
permissions to read and execute path components, while the former does
not.  That means that if our buffer is too small and we're missing
rights we could get EACCES, but we may succeed with a bigger buffer.

Keep retrying if getcwd(3) indicates lack of permissions until our
buffer can fit PATH_MAX bytes, as that's the maximum supported by the
syscall on FreeBSD anyway.  This way we do what we can to be able to
benefit from the syscall, but we also won't loop forever if there is a
real permission issue.

This fixes a regression introduced with 7333ed17 (setup: convert
setup_git_directory_gently_1 et al. to strbuf, 2014-07-28) for paths
longer than 127 bytes with components that miss read or execute
permissions (e.g. 0711 on /home for privacy reasons); we used a fixed
PATH_MAX-sized buffer before.

Reported-by: Zenobiusz Kunegunda <zenobiusz.kunegunda@interia.pl>
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-26 17:41:05 -07:00
Junio C Hamano f1fac407f5 Merge branch 'mm/reset-facl-before-umask-test'
Test tweaks for those who have default ACL in their git source tree
that interfere with the umask test.

* mm/reset-facl-before-umask-test:
  t0001: don't let a default ACL interfere with the umask test
2017-02-02 13:36:56 -08:00
Matt McCutchen d549d21307 t0001: don't let a default ACL interfere with the umask test
The "init creates a new deep directory (umask vs. shared)" test expects
the permissions of newly created files to be based on the umask, which
fails if a default ACL is inherited from the working tree for git.  So
attempt to remove a default ACL if there is one.  Same idea as
8ed0a740dd.  (I guess I'm the only one who
ever runs the test suite with a default ACL set.)

Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-30 14:03:21 -08:00
Nguyễn Thái Ngọc Duy 6311cfaf93 init: do not set unnecessary core.worktree
The function needs_work_tree_config() that is called from
create_default_files() is supposed to be fed the path to ".git" that
looks as if it is at the top of the working tree, and decide if that
location matches the actual worktree being used.  This comparison allows
"git init" to decide if core.worktree needs to be recorded in the
working tree.

In the current code, however, we feed the return value from
get_git_dir(), which can be totally different from what the function
expects when "gitdir" file is involved.  Instead of giving the path to
the ".git" at the top of the working tree, we end up feeding the actual
path that the file points at.

This original location of ".git" however is only known to init_db().
Make init_db() save it and have it passed to create_default_files() as a
new parameter, which passes the correct location down to
needs_work_tree_config() to fix this.

Noticed-by: Max Nordlund <max.nordlund@sqore.com>
Helped-by: Michael J Gruber <git@drmicha.warpmail.net>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-25 16:32:35 -07:00
Nguyễn Thái Ngọc Duy fe9aa0b22e init: correct re-initialization from a linked worktree
When 'git init' is called from a linked worktree, we treat '.git'
dir (which is $GIT_COMMON_DIR/worktrees/something) as the main
'.git' (i.e. $GIT_COMMON_DIR) and populate the whole repository skeleton
in there. It does not harm anything (*) but it is still wrong.

Since 'git init' calls set_git_dir() at preparation time, which
indirectly calls get_common_dir() and correctly detects multiple
worktree setup, all git_path_buf() calls in create_default_files() will
return correct paths in both single and multiple worktree setups. The
only thing left is copy_templates(), which targets $GIT_DIR, not
$GIT_COMMON_DIR.

Fix that with get_git_common_dir(). This function will return $GIT_DIR
in single-worktree setup, so we don't have to make a special case for
multiple-worktree here.

(*) It does in fact, thanks to another bug. More on that later.

Noticed-by: Max Nordlund <max.nordlund@sqore.com>
Helped-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-25 16:32:35 -07:00
Jeff King b9605bc4f2 config: only read .git/config from configured repos
When git_config() runs, it looks in the system, user-wide,
and repo-level config files. It gets the latter by calling
git_pathdup(), which in turn calls get_git_dir(). If we
haven't set up the git repository yet, this may simply
return ".git", and we will look at ".git/config".  This
seems like it would be helpful (presumably we haven't set up
the repository yet, so it tries to find it), but it turns
out to be a bad idea for a few reasons:

  - it's not sufficient, and therefore hides bugs in a
    confusing way. Config will be respected if commands are
    run from the top-level of the working tree, but not from
    a subdirectory.

  - it's not always true that we haven't set up the
    repository _yet_; we may not want to do it at all. For
    instance, if you run "git init /some/path" from inside
    another repository, it should not load config from the
    existing repository.

  - there might be a path ".git/config", but it is not the
    actual repository we would find via setup_git_directory().
    This may happen, e.g., if you are storing a git
    repository inside another git repository, but have
    munged one of the files in such a way that the
    inner repository is not valid (e.g., by removing HEAD).

We have at least two bugs of the second type in git-init,
introduced by ae5f677 (lazily load core.sharedrepository,
2016-03-11). It causes init to use git_configset(), which
loads all of the config, including values from the current
repo (if any).  This shows up in two ways:

  1. If we happen to be in an existing repository directory,
     we'll read and respect core.sharedrepository from it,
     even though it should have no bearing on the new
     repository. A new test in t1301 covers this.

  2. Similarly, if we're in an existing repo that sets
     core.logallrefupdates, that will cause init to fail to
     set it in a newly created repository (because it thinks
     that the user's templates already did so). A new test
     in t0001 covers this.

We also need to adjust an existing test in t1302, which
gives another example of why this patch is an improvement.

That test creates an embedded repository with a bogus
core.repositoryformatversion of "99". It wants to make sure
that we actually stop at the bogus repo rather than
continuing upward to find the outer repo. So it checks that
"git config core.repositoryformatversion" returns 99. But
that only works because we blindly read ".git/config", even
though we _know_ we're in a repository whose vintage we do
not understand.

After this patch, we avoid reading config from the unknown
vintage repository at all, which is a safer choice.  But we
need to tweak the test, since core.repositoryformatversion
will not return 99; it will claim that it could not find the
variable at all.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-13 15:45:45 -07:00
Johannes Schindelin f30afdabbf mingw: introduce the 'core.hideDotFiles' setting
On Unix (and Linux), files and directories whose names start with a dot
are usually not shown by default. This convention is used by Git: the
.git/ directory should be left alone by regular users, and only accessed
through Git itself.

On Windows, no such convention exists. Instead, there is an explicit flag
to mark files or directories as hidden.

In the early days, Git for Windows did not mark the .git/ directory (or
for that matter, any file or directory whose name starts with a dot)
hidden. This lead to quite a bit of confusion, and even loss of data.

Consequently, Git for Windows introduced the core.hideDotFiles setting,
with three possible values: true, false, and dotGitOnly, defaulting to
marking only the .git/ directory as hidden.

The rationale: users do not need to access .git/ directly, and indeed (as
was demonstrated) should not really see that directory, either. However,
not all dot files should be hidden by default, as e.g. Eclipse does not
show them (and the user would therefore be unable to see, say, a
.gitattributes file).

In over five years since the last attempt to bring this patch into core
Git, a slightly buggy version of this patch has served Git for Windows'
users well: no single report indicated problems with the hidden .git/
directory, and the stream of problems caused by the previously non-hidden
.git/ directory simply stopped. The bugs have been fixed during the
process of getting this patch upstream.

Note that there is a funny quirk we have to pay attention to when
creating hidden files: we use Win32's _wopen() function which
transmogrifies its arguments and hands off to Win32's CreateFile()
function. That latter function errors out with ERROR_ACCESS_DENIED (the
equivalent of EACCES) when the equivalent of the O_CREAT flag was passed
and the file attributes (including the hidden flag) do not match an
existing file's. And _wopen() accepts no parameter that would be
transmogrified into said hidden flag. Therefore, we simply try again
without O_CREAT.

A slightly different method is required for our fopen()/freopen()
function as we cannot even *remove* the implicit O_CREAT flag.
Therefore, we briefly mark existing files as unhidden when opening them
via fopen()/freopen().

The ERROR_ACCESS_DENIED error can also be triggered by opening a file
that is marked as a system file (which is unlikely to be tracked in
Git), and by trying to create a file that has *just* been deleted and is
awaiting the last open handles to be released (which would be handled
better by the "Try again?" logic, a story for a different patch series,
though). In both cases, it does not matter much if we try again without
the O_CREAT flag, read: it does not hurt, either.

For details how ERROR_ACCESS_DENIED can be triggered, see
https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858

Original-patch-by: Erik Faye-Lund <kusmabite@gmail.com>
Initial-Test-By: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-11 13:54:53 -07:00
Junio C Hamano 28ab768afa Merge branch 'nd/clear-gitenv-upon-use-of-alias'
Hotfix for a test breakage made between 2.7 and 'master'.

* nd/clear-gitenv-upon-use-of-alias:
  t0001: fix GIT_* environment variable check under --valgrind
2016-03-04 13:46:44 -08:00
Johannes Sixt f3858f8edc t0001: fix GIT_* environment variable check under --valgrind
When a test case is run without --valgrind, the wrap-for-bin.sh
helper script inserts the environment variable GIT_TEXTDOMAINDIR, but
when run with --valgrind, the variable is missing. A recently
introduced test case expects the presence of the variable, though, and
fails under --valgrind.

Rewrite the test case to strip conditially defined environment variables
from both expected and actual output.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-03 08:55:13 -08:00
Junio C Hamano 5135d1c3d2 Merge branch 'nd/clear-gitenv-upon-use-of-alias'
d95138e6 (setup: set env $GIT_WORK_TREE when work tree is set, like
$GIT_DIR, 2015-06-26) attempted to work around a glitch in alias
handling by overwriting GIT_WORK_TREE environment variable to
affect subprocesses when set_git_work_tree() gets called, which
resulted in a rather unpleasant regression to "clone" and "init".
Try to address the same issue by always restoring the environment
and respawning the real underlying command when handling alias.

* nd/clear-gitenv-upon-use-of-alias:
  run-command: don't warn on SIGPIPE deaths
  git.c: make sure we do not leak GIT_* to alias scripts
  setup.c: re-fix d95138e (setup: set env $GIT_WORK_TREE when ..
  git.c: make it clear save_env() is for alias handling only
2016-01-20 11:43:26 -08:00
Nguyễn Thái Ngọc Duy 57ea7123c8 git.c: make sure we do not leak GIT_* to alias scripts
The unfortunate commit d95138e (setup: set env $GIT_WORK_TREE when
work tree is set, like $GIT_DIR - 2015-06-26) exposes another problem,
besides git-clone that's described in the previous commit. If
GIT_WORK_TREE (or even GIT_DIR) is exported to an alias script, it may
mislead git commands in the script where the repo is. Granted, most
scripts work on the repo where the alias is summoned from. But nowhere
do we forbid the script to visit another repository.

The revert of d95138e in the previous commit is sufficient as a
fix. However, to protect us from accidentally leaking GIT_*
environment variables again, we restore certain sensitive env before
calling the external script.

GIT_PREFIX is let through because there's another setup side effect
that we simply accepted so far: current working directory is
moved. Maybe in future we can introduce a new alias format that
guarantees no cwd move, then we can unexport GIT_PREFIX.

Reported-by: Gabriel Ganne <gabriel.ganne@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-22 13:40:32 -08:00
Jeff King 9c28390bda init: use strbufs to store paths
The init code predates strbufs, and uses PATH_MAX-sized
buffers along with many manual checks on intermediate sizes
(some of which make magic assumptions, such as that init
will not create a path inside .git longer than 50
characters).

We can simplify this greatly by using strbufs, which drops
some hard-to-verify strcpy calls in favor of git_path_buf.
While we're in the area, let's also convert existing calls
to git_path to the safer git_path_buf (our existing calls
were passed to pretty tame functions, and so were not a
problem, but it's easy to be consistent and safe here).

Note that we had an explicit test that "git init" rejects
long template directories. This comes from 32d1776 (init: Do
not segfault on big GIT_TEMPLATE_DIR environment variable,
2009-04-18). We can drop the test_must_fail here, as we now
accept this and need only confirm that we don't segfault,
which was the original point of the test.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-05 11:07:04 -07:00
Junio C Hamano a633732440 Merge branch 'mh/config-flip-xbit-back-after-checking'
* mh/config-flip-xbit-back-after-checking:
  create_default_files(): don't set u+x bit on $GIT_DIR/config
2014-12-05 11:43:10 -08:00
Michael Haggerty 1f32ecffd8 create_default_files(): don't set u+x bit on $GIT_DIR/config
Since time immemorial, the test of whether to set "core.filemode"
has been done by trying to toggle the u+x bit on $GIT_DIR/config,
which we know always exists, and then testing whether the change
"took".  I find it somewhat odd to use the config file for this
test, but whatever.

The test code didn't set the u+x bit back to its original state
itself, instead relying on the subsequent call to git_config_set()
to re-write the config file with correct permissions.

But ever since

    daa22c6f8d config: preserve config file permissions on edits (2014-05-06)

git_config_set() copies the permissions from the old config file to
the new one.  This is a good change in and of itself, but it
invalidates the create_default_files()'s assumption, causing "git
init" to leave the executable bit set on $GIT_DIR/config.

Reset the permissions on $GIT_DIR/config when we are done with the
test in create_default_files().

Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-18 10:10:54 -08:00
Junio C Hamano b30adaac52 Merge branch 'nd/init-restore-env'
Some subcommands do not want to be aliased because of the side
effects that happens while the definitions of the aliases are looked
up from configuration system.

* nd/init-restore-env:
  git potty: restore environments after alias expansion
2014-06-25 12:22:00 -07:00
Nguyễn Thái Ngọc Duy c0562611c5 git potty: restore environments after alias expansion
Commit 4ad8332 (t0001: test git init when run via an alias -
2010-11-26) noted breakages when running init via alias. The problem
is for alias to be used, $GIT_DIR must be searched, but 'init' and
'clone' are not happy with that. So we start a new process like an
external command, with clean environment in this case. Env variables
that are set by command line (e.g. "git --git-dir=.. ") are kept.

This should also fix autocorrecting a command typo to "init" because
it's the same problem: aliases are read, then "init" is unhappy with
$GIT_DIR already set up because of that.

Reminded-by: David Turner <dturner@twopensource.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-10 12:00:53 -07:00
Junio C Hamano 6753d8a85d Merge branch 'ep/shell-command-substitution'
Adjust shell scripts to use $(cmd) instead of `cmd`.

* ep/shell-command-substitution: (41 commits)
  t5000-tar-tree.sh: use the $( ... ) construct for command substitution
  t4204-patch-id.sh: use the $( ... ) construct for command substitution
  t4119-apply-config.sh: use the $( ... ) construct for command substitution
  t4116-apply-reverse.sh: use the $( ... ) construct for command substitution
  t4057-diff-combined-paths.sh: use the $( ... ) construct for command substitution
  t4038-diff-combined.sh: use the $( ... ) construct for command substitution
  t4036-format-patch-signer-mime.sh: use the $( ... ) construct for command substitution
  t4014-format-patch.sh: use the $( ... ) construct for command substitution
  t4013-diff-various.sh: use the $( ... ) construct for command substitution
  t4012-diff-binary.sh: use the $( ... ) construct for command substitution
  t4010-diff-pathspec.sh: use the $( ... ) construct for command substitution
  t4006-diff-mode.sh: use the $( ... ) construct for command substitution
  t3910-mac-os-precompose.sh: use the $( ... ) construct for command substitution
  t3905-stash-include-untracked.sh: use the $( ... ) construct for command substitution
  t1050-large.sh: use the $( ... ) construct for command substitution
  t1020-subdirectory.sh: use the $( ... ) construct for command substitution
  t1004-read-tree-m-u-wf.sh: use the $( ... ) construct for command substitution
  t1003-read-tree-prefix.sh: use the $( ... ) construct for command substitution
  t1002-read-tree-m-u-2way.sh: use the $( ... ) construct for command substitution
  t1001-read-tree-m-2way.sh: use the $( ... ) construct for command substitution
  ...
2014-06-03 12:06:45 -07:00
Elia Pinto 88619b3ee4 t0001-init.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command
substitution instead of using the backquotes `...`.

The backquoted form is the traditional method for command
substitution, and is supported by POSIX.  However, all but the
simplest uses become complicated quickly.  In particular, embedded
command substitutions and/or the use of double quotes require
careful escaping with the backslash character.

The patch was generated by:

for _f in $(find . -name "*.sh")
do
   sed -i 's@`\(.*\)`@$(\1)@g' ${_f}
done

and then carefully proof-read.

Signed-off-by: Elia Pinto <gitter.spiros@gmail.com>
Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-29 12:44:22 -07:00
Jeff King 410c3428ed t0001: drop subshells just for "cd"
Many tests do something like:

  (
	mkdir foo &&
	cd foo &&
	git init
  )

You can do the same these days with "git init foo", which
makes the tests shorter and simpler to read.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 14:35:13 -07:00
Jeff King 99e1c7367f t0001: drop useless subshells
Many tests use subshells, but don't actually change the
shell environment. They were probably cargo-culted from
earlier tests which did need subshells. Drop the useless
ones.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 14:35:08 -07:00
Jeff King 0981140fcc t0001: use test_must_fail
We've hand-rolled several "if" statements looking for
failures. We can use test_must_fail here, which is shorter
and more robust.

Note that we modify the commands slightly (to use "git init
foo" rather than "cd foo && git init") to avoid dealing with
a subshell, but this should not affect the outcome.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 14:28:05 -07:00
Jeff King 2a472410cb t0001: use test_config_global
We hand-set several config options using :

  git config -f $HOME/.gitconfig ...

Instead, we can use "test_config_global". Not only is this
more readable, but it cleans up for us so that subsequent
tests aren't polluted by our settings.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 14:28:03 -07:00
Jeff King 633734d4a1 t0001: use test_path_is_*
t0001 predates the test_path_is_* helpers, and uses "test
-f" and "test -d" directly. Using the helpers provides
better debugging output, and are a little more robust.
As opposed to "! test -d", test_path_is_missing will
actually makes sure the path does not exist at all.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 14:27:58 -07:00
Jeff King 3d06c5f19d t0001: make symlink reinit test more careful
In the final test of t0001, we have a repo whose .git is a
symlink to a directory "here", and we use
"--separate-git-dir" to migrate that to a .git file pointing
to a different directory. We check that the data is migrated
to the new directory and that .git looks like a git-file.

We also check that "here" is not a directory, which is
slightly misleading. It should not be a directory, but
neither should it be gone. It is the actual resting place of
the git-file, and .git remains a symlink to it.

Let's check that more explicitly, both to make our test more
robust, and to make further cleanups in this area more
obvious.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 14:27:52 -07:00
Jeff King 3cc6a6f0f7 t: stop using GIT_CONFIG to cross repo boundaries
Some tests want to check or set config in another
repository. E.g., t1000 creates repositories and makes sure
that their core.bare and core.worktree settings are what we
expect. We can do this with:

  GIT_CONFIG=$repo/.git/config git config ...

but it better shows the intent to just enter the repository
and let "git config" do the normal lookups:

  (cd $repo && git config ...)

In theory, this would cause us to use an extra subshell, but
in all such cases, we are actually already in a subshell.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 14:24:40 -07:00
Jeff King 221bf98506 t: drop useless sane_unset GIT_* calls
Several test scripts manually unset GIT_CONFIG and other
GIT_* variables. These are generally taken care of for us by
test-lib.sh already.

Unsetting these is not only useless, but can be confusing to
a reader, who may wonder why some tests in a script unset
them and others do not (t0001 is particularly guilty of this
inconsistency, probably because many of its tests predate
the test-lib.sh environment-cleansing).

Note that we cannot always get rid of such unsetting. For
example, t9130 can drop the GIT_CONFIG unset, but not the
GIT_DIR one, because lib-git-svn.sh sets the latter. And in
t1000, we unset GIT_TEMPLATE_DIR, which is explicitly
initialized by test-lib.sh.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-21 14:11:11 -07:00
Nguyễn Thái Ngọc Duy 487a2b7322 Make setup_git_env() resolve .git file when $GIT_DIR is not specified
This makes reinitializing on a .git file repository work.

This is probably the only case that setup_git_env() (via
set_git_dir()) is called on a .git file. Other cases in
setup_git_dir_gently() and enter_repo() both cover .git file case
explicitly because they need to verify the target repo is valid.

Reported-by: Ximin Luo <infinity0@gmx.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-03 11:14:58 -07:00
Junio C Hamano 6741c2e64a Merge branch 'maint'
* maint:
  init/clone: remove short option -L and document --separate-git-dir
2011-05-25 15:25:44 -07:00
Nguyen Thai Ngoc Duy 09ffc706e4 init/clone: remove short option -L and document --separate-git-dir
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-25 09:30:26 -07:00
Junio C Hamano a75c3523d3 Merge branch 'ab/i18n-fixup'
* ab/i18n-fixup: (24 commits)
  i18n: use test_i18n{cmp,grep} in t7600, t7607, t7611 and t7811
  i18n: use test_i18n{grep,cmp} in t7508
  i18n: use test_i18ngrep in t7506
  i18n: use test_i18ngrep and test_i18ncmp in t7502
  i18n: use test_i18ngrep in t7501
  i18n: use test_i18ncmp in t7500
  i18n: use test_i18ngrep in t7201
  i18n: use test_i18ncmp and test_i18ngrep in t7102 and t7110
  i18n: use test_i18ncmp and test_i18ngrep in t5541, t6040, t6120, t7004, t7012 and t7060
  i18n: use test_i18ncmp and test_i18ngrep in t3700, t4001 and t4014
  i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507
  i18n: use test_i18ngrep in t2020, t2204, t3030, and t3200
  i18n: use test_i18ngrep in lib-httpd and t2019
  i18n: do not overuse C_LOCALE_OUTPUT (grep)
  i18n: use test_i18ncmp in t1200 and t2200
  i18n: .git file is not a human readable message (t5601)
  i18n: do not overuse C_LOCALE_OUTPUT
  i18n: mark init-db messages for translation
  i18n: mark checkout plural warning for translation
  i18n: mark checkout --detach messages for translation
  ...
2011-05-02 15:58:40 -07:00
Junio C Hamano 127df8c6cf i18n: do not overuse C_LOCALE_OUTPUT (grep)
Instead of skipping the whole test, introduce test_i18ngrep wrapper that
pretends a successful result under GETTEXT_POISON build.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13 15:52:47 -07:00
Junio C Hamano 5dee1532e1 Merge branch 'nd/init-gitdir'
* nd/init-gitdir:
  t0001: guard a new test with SYMLINKS prerequisite
2011-04-12 00:04:53 -07:00
Johannes Sixt 4e95fb6c37 t0001: guard a new test with SYMLINKS prerequisite
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-11 23:57:56 -07:00
Junio C Hamano c4b2ce6953 Merge branch 'nd/init-gitdir'
* nd/init-gitdir:
  init, clone: support --separate-git-dir for .git file
  git-init.txt: move description section up

Conflicts:
	builtin/clone.c
2011-04-01 17:57:37 -07:00
Junio C Hamano 6c80cd298a Merge branch 'ab/i18n-st'
* ab/i18n-st: (69 commits)
  i18n: git-shortlog basic messages
  i18n: git-revert split up "could not revert/apply" message
  i18n: git-revert literal "me" messages
  i18n: git-revert "Your local changes" message
  i18n: git-revert basic messages
  i18n: git-notes GIT_NOTES_REWRITE_MODE error message
  i18n: git-notes basic commands
  i18n: git-gc "Auto packing the repository" message
  i18n: git-gc basic messages
  i18n: git-describe basic messages
  i18n: git-clean clean.requireForce messages
  i18n: git-clean basic messages
  i18n: git-bundle basic messages
  i18n: git-archive basic messages
  i18n: git-status "renamed: " message
  i18n: git-status "Initial commit" message
  i18n: git-status "Changes to be committed" message
  i18n: git-status shortstatus messages
  i18n: git-status "nothing to commit" messages
  i18n: git-status basic messages
  ...

Conflicts:
	builtin/branch.c
	builtin/checkout.c
	builtin/clone.c
	builtin/commit.c
	builtin/grep.c
	builtin/merge.c
	builtin/push.c
	builtin/revert.c
	t/t3507-cherry-pick-conflict.sh
	t/t7607-merge-overwrite.sh
2011-04-01 17:55:55 -07:00
Nguyễn Thái Ngọc Duy b57fb80a7d init, clone: support --separate-git-dir for .git file
--separate-git-dir tells git to create git dir at the specified
location, instead of where it is supposed to be. A .git file that
points to that location will be put in place so that it appears normal
to repo discovery process.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-19 21:48:19 -07:00
Jonathan Nieder 8f323c00dd config: drop support for GIT_CONFIG_NOGLOBAL
Now that test-lib sets $HOME to protect against pollution from user
settings, GIT_CONFIG_NOGLOBAL is not needed for use by the test
suite any more.  And as luck would have it, a quick code search
reveals no other users in the wild.

This patch does not affect GIT_CONFIG_NOSYSTEM, which is still
needed.

Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-15 12:23:30 -07:00
Ævar Arnfjörð Bjarmason 3e5dd7e960 i18n: git-init "Initialized [...] repository" message
These messages could benefit from splitting up.  An earlier version of
this patch began like this:

    const char *reinit_shared   = _("Reinitialized existing shared Git repository in %s\n");
    const char *init_shared     = _("Initialized empty shared Git repository in %s\n");
    const char *reinit_noshared = _("Reinitialized existing Git repository in %s\n");
    const char *init_noshared   = _("Initialized empty Git repository in %s\n");

But in the first round of gettextization I'm aiming to keep code
changes to a minimum for ease of review.  So just add a comment
explaining to translators how the sprintf format gets used so they
can cope for now if the language's grammar allows.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09 23:52:52 -08:00
Brandon Casey ed40ec551d t0001,t1510,t3301: use sane_unset which always returns with status 0
On some shells (like /usr/xpg4/bin/sh on Solaris), unset will exit
non-zero when passed the name of a variable that has not been set.  Use
sane_unset instead so that the return value of unset can be ignored while
the && linkage of the test script can be preserved.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-06 12:22:36 -08:00
Junio C Hamano f3bb8b4b84 Merge branch 'nd/setup'
* nd/setup: (47 commits)
  setup_work_tree: adjust relative $GIT_WORK_TREE after moving cwd
  git.txt: correct where --work-tree path is relative to
  Revert "Documentation: always respect core.worktree if set"
  t0001: test git init when run via an alias
  Remove all logic from get_git_work_tree()
  setup: rework setup_explicit_git_dir()
  setup: clean up setup_discovered_git_dir()
  t1020-subdirectory: test alias expansion in a subdirectory
  setup: clean up setup_bare_git_dir()
  setup: limit get_git_work_tree()'s to explicit setup case only
  Use git_config_early() instead of git_config() during repo setup
  Add git_config_early()
  git-rev-parse.txt: clarify --git-dir
  t1510: setup case #31
  t1510: setup case #30
  t1510: setup case #29
  t1510: setup case #28
  t1510: setup case #27
  t1510: setup case #26
  t1510: setup case #25
  ...
2010-12-28 11:26:55 -08:00
Jonathan Nieder 4ad8332ef7 t0001: test git init when run via an alias
Add some tests to document the correct behavior of (possibly aliased)
init when run within and outside a git directory.

If I set up a simple git alias “quietinit = init --quiet”, usually it
will work just like ‘git init --quiet’.

There are some differences, unfortunately, since in the process of
checking for aliases, git has to look for a .git/config file.  If ‘git
quietinit’ is run from a subdirectory of an existing git repository,
that repository’s configuration will affect the configuration of the
new repository.  In particular, the new repository can inherit
bogus values for core.bare and core.worktree.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-12-22 14:34:24 -08:00
Elijah Newren 00648ba050 Introduce sane_unset and use it to ensure proper && chaining
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-06 13:26:33 -07:00
Matthieu Moy e4c62e640d tests: factor HOME=$(pwd) in test-lib.sh
The same pattern is used in many tests, and makes it easy for new ones to
rely on $HOME being a trashable, clean, directory.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-31 12:12:02 -07:00
Ævar Arnfjörð Bjarmason c91cfd1916 tests: A SANITY test prereq for testing if we're root
Some tests depend on not being able to write to files after chmod
-w. This doesn't work when running the tests as root.

Change test-lib.sh to test if this works, and if so it sets a new
SANITY test prerequisite. The tests that use this previously failed
when run under root.

There was already a test for this in t3600-rm.sh, added by Junio C
Hamano in 2283645 in 2006. That check now uses the new SANITY
prerequisite.

Some of this was resurrected from the "Tests in Cygwin" thread in May
2009:

    http://thread.gmane.org/gmane.comp.version-control.git/116729/focus=118385

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-18 12:42:04 -07:00
Jeff King 87a074df24 handle "git --bare init <dir>" properly
If we know we are creating a bare repository, we use setenv
to set the GIT_DIR directory to the current directory
(either where we already were, or one we created and chdir'd
into with "git init --bare <dir>").

However, with "git --bare init <dir>" (note the --bare as a
git wrapper option), the setup code actually sets GIT_DIR
for us, but it uses the wrong, original cwd when a directory
is given. Because our setenv does not use the overwrite
flag, it is ignored.

We need to set the overwrite flag, but only when we are
given a directory on the command line. That still allows:

  GIT_DIR=foo.git git init --bare

to work. The behavior is changed for:

  GIT_DIR=foo.git git init --bare bar.git

which used to create the repository in foo.git, but now will
use bar.git. This is more sane, as command line options
should generally override the environment.

Noticed by Oliver Hoffmann.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-05-10 11:25:37 -07:00
Steven Drake a94d305bf8 t/t0001-init.sh: add test for 'init with init.templatedir set'
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>
2010-02-25 22:47:48 -08:00
Johannes Sixt d82e75e86c t0001-init: split the existence test from the permission test
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>
2009-08-09 10:43:24 -07:00
Johannes Sixt 7d53a07a28 t0001-init: fix a file name
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>
2009-08-09 10:41:37 -07:00
Nanako Shiraishi 53d4888593 git init: optionally allow a directory argument
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>
2009-07-25 02:17:54 -07:00