* 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
...
When setup_work_tree() is called, it moves cwd to $GIT_WORK_TREE and
makes internal copy of $GIT_WORK_TREE absolute. The environt variable,
if set by user, remains unchanged. If the variable is relative, it is
no longer correct because its base dir has changed.
Instead of making $GIT_WORK_TREE absolute too, we just say "." and let
subsequent git processes handle it.
Reported-by: Michel Briand <michelbriand@free.fr>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function is the most complex one among the three setup_*
functions because all GIT_DIR, GIT_WORK_TREE, core.worktree and
core.bare are involved.
Because core.worktree is only effective inside
setup_explicit_git_dir() and the extra code in setup_git_directory()
is to handle that. The extra code can now be retired.
Also note that setup_explicit assignment is removed, worktree setting
is no longer decided by get_git_work_tree(). get_git_work_tree() will
be simplified in the next commit.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If core.bare is true, discard the discovered worktree, move back to
original cwd.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
work_tree_env argument is removed because this function does not need
it. GIT_WORK_TREE is only effective inside setup_explicit_git_dir.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
get_git_work_tree() takes input as core.worktree, core.bare,
GIT_WORK_TREE and decides correct worktree setting.
Unfortunately it does not do its job well. core.worktree and
GIT_WORK_TREE should only be taken into account, if GIT_DIR is set
(which is handled by setup_explicit_git_dir). For other setup cases,
only core.bare matters.
Add a temporary variable setup_explicit to adjust get_git_work_tree()
behavior as such. This variable will be gone once setup_* rework is
done.
Also remove is_bare_repository_cfg check in set_git_work_tree() to
ease the rework. We are going to check for core.bare and core.worktree
early before setting worktree. For example, if core.bare is true, no
need to set worktree.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git_config() is called, either git_dir has already been set (by
$GIT_DIR env or set_git_dir()), or it will default git_dir to ".git".
git_config_early() gives setup functions more freedom because it does
not require git_dir. Give it a config path, it will happily examine
it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/extended-sha1-relpath:
get_sha1: teach ":$n:<path>" the same relative path logic
get_sha1: support relative path ":path" syntax
Make prefix_path() return char* without const
Conflicts:
sha1_name.c
* jn/parse-options-extra:
update-index: migrate to parse-options API
setup: save prefix (original cwd relative to toplevel) in startup_info
parse-options: make resuming easier after PARSE_OPT_STOP_AT_NON_OPTION
parse-options: allow git commands to invent new option types
parse-options: never suppress arghelp if LITERAL_ARGHELP is set
parse-options: do not infer PARSE_OPT_NOARG from option type
parse-options: sanity check PARSE_OPT_NOARG flag
parse-options: move NODASH sanity checks to parse_options_check
parse-options: clearer reporting of API misuse
parse-options: Don't call parse_options_check() so much
prefix_path() allocates new buffer. There's no reason for it to keep
the buffer for itself and waste memory.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Save the path from the original cwd to the cwd at the end of the
setup procedure in the startup_info struct introduced in e37c1329
(2010-08-05). The value cannot vary from thread to thread anyway,
since the cwd is global.
So now in your builtin command, instead of passing prefix around,
when you want to convert a user-supplied path to a cwd-relative
path, you can use startup_info->prefix directly.
Caveat: As with the return value from setup_git_directory_gently(),
startup_info->prefix would be NULL when the original cwd is not a
subdir of the toplevel.
Longer term, this would allow the prefix to be reused when several
noncooperating functions require access to the same repository (for
example, when accessing configuration before running a builtin).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Current prefix_filename() is proofed against the case where the prefix
'pfx' is NULL or a 0-length string, _except on Windows_.
Change the behaviour to work the same on both platforms, and only
check pfx_len so that callers passing a NULL prefix with a nonzero
pfx_len segfault early on both.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/paginate-fix:
t7006 (pager): add missing TTY prerequisites
merge-file: run setup_git_directory_gently() sooner
var: run setup_git_directory_gently() sooner
ls-remote: run setup_git_directory_gently() sooner
index-pack: run setup_git_directory_gently() sooner
config: run setup_git_directory_gently() sooner
bundle: run setup_git_directory_gently() sooner
apply: run setup_git_directory_gently() sooner
grep: run setup_git_directory_gently() sooner
shortlog: run setup_git_directory_gently() sooner
git wrapper: allow setup_git_directory_gently() be called earlier
setup: remember whether repository was found
git wrapper: introduce startup_info struct
Conflicts:
builtin/index-pack.c
* 'jn/maint-setup-fix' (early part):
Revert "rehabilitate 'git index-pack' inside the object store"
setup: do not forget working dir from subdir of gitdir
t4111 (apply): refresh index before applying patches to it
setup: split off get_device_or_die helper
setup: split off a function to handle hitting ceiling in repo search
setup: split off code to handle stumbling upon a repository
setup: split off a function to checks working dir for .git file
setup: split off $GIT_DIR-set case from setup_git_directory_gently
tests: try git apply from subdir of toplevel
t1501 (rev-parse): clarify
As v1.7.2~16^2 (git --paginate: paginate external commands
again, 2010-07-14) explains, builtins (like git config) that
do not use RUN_SETUP are not finding GIT_DIR set correctly when
it is time to launch the pager from run_builtin(). If they
were to search for a repository sooner, then the outcome of such
early repository accesses would be more predictable and reliable.
The cmd_*() functions learn whether a repository was found through the
*nongit_ok return value from setup_git_directory_gently(). If
run_builtin() is to take care of the repository search itself, that
datum needs to be retrievable from somewhere else. Use the
startup_info struct for this.
As a bonus, this information becomes available to functions such as
git_config() which might want to avoid trying to access a repository
when none is present.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Finish the clean-up of setup_git_directory_gently() by splitting the
last case of validation+setup (global variables, prefix, check_format,
set_git_dir) into its own function. Now setup_git_git_directory_gently
itself takes care of discovery only and the functions that pick up
from there are nearby in the source file so they can be easily
compared.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
v1.6.1.3~4^2 (Fix gitdir detection when in subdir of gitdir,
2009-01-16) did not go far enough: when a git directory is
an ancestor of the original working directory, not only
should GIT_DIR be set to point to the .git directory, but
the original working directory should be restored before
carrying out the relevant command.
This way, the effect of running a git command from a subdir
of .git will be the same whether or not GIT_DIR is explicitly
set.
Noticed while investigating v1.6.0.3~1 (rehabilitate 'git
index-pack' inside the object store, 2008-10-20).
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This does not eliminate any code, but it skims some off of
the main loop of setup_git_directory_gently so that can be
understood more easily.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Perhaps some day, other similar conditions (hitting the mount point,
hitting the root of the file system) will share this code.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a repository is found as an ancestor of the original
working directory, it is assumed by default to be bare.
Handle this case with its own function.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The repository discovery procedure looks something like this:
while (same filesystem) {
check .git in working dir
check .
chdir(..)
}
Add a function for the first step to make the actual code look a bit
closer to that pseudocode.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If $GIT_DIR is set, setup_git_directory_gently does not have
to do any repository discovery at all. Split off a function
for the validation it still does do, in the hope that this will
make setup_git_directory_gently proper less daunting to read.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This prevents a buffer overrun that could otherwise be triggered by
creating a file called '.git' with contents
gitdir: (something really long)
Signed-off-by: Greg Brockman <gdb@mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original declaration was int, which seems to cause trouble on my
machine. It causes spurious "filesystem boundary" errors when running
the testsuite. The cause seems to be
$ stat -c%d .
2147549952
which is too large for a 32-bit int type.
Using the correct type, dev_t, solves the issue. (Because I'm
paranoid and forgetful, I checked -- yes, Unix v7 had dev_t.)
Other uses of st_dev seem to be reasonably safe. fill_stat_cache_info
truncates it to an 'unsigned int', but that value seems to be used only
to validate the cache, and only if USE_STDEV is defined.
Signed-off-by: Raja R Harinath <harinath@hurrynot.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a missing ONE_FILESYSTEM defaults to true, the only users who set this
variable set it to false to tell git not to limit the discovery to one
filesystem; there are too many negations in one sentence to make a simple
panda brain dizzy.
Use the variable GIT_DISCOVERY_ACROSS_FILESYSTEM that changes the
behaviour from the default "limit to one filesystem" to "cross the
boundary as I ask you to"; makes the semantics much more straight
forward.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Regarding the new environment variable, Linus Torvalds
<torvalds@linux-foundation.org> writes on Tue, 30 Mar 2010 in
<alpine.LFD.2.00.1003301537150.3707@i5.linux-foundation.org>:
I suspect that it is _very_ unusual to have a source repo that crosses
multiple filesystems, and the original reason for this patch-series
seems to me to be likely to be more common than that multi-fs case. So
having the logic go the other way would seem to match the common case,
no?
The "crossing filesystem boundary" condition is checked by comparing
st_dev field in the result from stat(2). This is slightly worrysome if
non-POSIX ports return different values in the field even for directories
in the same work tree extracted to the same "filesystem". Erik Faye-Lund
confirms that in the msysgit port st_dev is 0, so this should be safe, as
"even Windows is safe" ;-)
This will affect those who use /.git to cram /etc and /home/me in the same
repostiory, /home is mounted from non-root filesystem, and a git operation
is done from inside /home/me/src. But that is such a corner case we don't
want to give preference over helping people who will benefit from having
this default so that they do not have to suffer from slow automounters.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch makes git pay attention to the GIT_ONE_FILESYSTEM environment
variable. When that variable is set, git will stop searching for a
GIT_DIR when it attempts to cross a filesystem boundary.
When working in an environment with too many automount points to make
maintaining a GIT_CEILING_DIRECTORIES list enjoyable, GIT_ONE_FILESYSTEM
gives the option of turning all such attempts off with one setting.
Signed-off-by: Lars R. Damerow <lars@pixar.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this truncation the error message printed only shows the cwd
from the start of the search, not where it failed.
Signed-off-by: Lars R. Damerow <lars@pixar.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* nd/root-git:
Add test for using Git at root of file system
Support working directory located at root
Move offset_1st_component() to path.c
init-db, rev-parse --git-dir: do not append redundant slash
make_absolute_path(): Do not append redundant slash
Conflicts:
setup.c
sha1_file.c
Git should work regardless where the working directory is located,
even at root. This patch fixes two places where it assumes working
directory always have parent directory.
In setup_git_directory_gently(), when Git goes up to root and finds
.git there, it happily sets worktree to "" instead of "/".
In prefix_path(), loosen the outside repo check a little bit. Usually
when a path XXX is inside worktree /foo, it must be either "/foo", or
"/foo/...". When worktree is simply "/", we can safely ignore the
check: we have a slash at the beginning already.
Not related to worktree, but also set gitdir correctly if a bare repo
is placed (insanely?) at root.
Thanks João Carlos Mendes Luís for pointing out this problem.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch converts the setenv() calls in path.c and setup.c. After
the call, git grep with a pager works again in bare repos.
It leaves the setenv(GIT_DIR_ENVIRONMENT, ...) calls in git.c alone, as
they respond to command line switches that emulate the effect of setting
the environment variable directly.
The remaining site in environment.c is in set_git_dir() and is left
alone, too, of course. Finally, builtin-init-db.c is left changed
because the repo is still being carefully constructed when the
environment variable is set.
This fixes git shortlog when run inside a git directory, which had been
broken by abe549e1.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 842abf0 (Teach resolve_gitlink_ref() about the .git file, 2008-02-20)
taught resolve_gitlink_ref() to call read_gitfile_gently() to resolve .git
files. In this commit teach read_gitfile_gently() to interpret a relative
path in a .git file with respect to the file location.
This change allows update-index to recognize a submodule that uses a relative
path in its .git file. It previously failed because the relative path was
wrongly interpreted with respect to the superproject directory.
Signed-off-by: Brad King <brad.king@kitware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Git 1.6.5.7
worktree: don't segfault with an absolute pathspec without a work tree
ignore unknown color configuration
help.autocorrect: do not run a command if the command given is junk
Illustrate "filter" attribute with an example
If a command is run with an absolute path as a pathspec inside a bare
repository, e.g. "rev-list HEAD -- /home", the code tried to run strlen()
on NULL, which is the result of get_git_work_tree(), and segfaulted. It
should just fail instead.
Currently the function returns NULL even inside .git/ in a repository
with a work tree, but that is a separate issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous error message was the same in many situations (unknown
revision or path not in the working tree). We try to help the user as
much as possible to understand the error, especially with the
sha1:filename notation. In this case, we say whether the sha1 or the
filename is problematic, and diagnose the confusion between
relative-to-root and relative-to-$PWD confusion precisely.
The 7 new error messages are tested.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it possible to invole the logic of verify_filename() to make sure the
pathname arguments are unambiguous without actually dying. The caller may
want to do something different.
The code which is conditional on MinGW32 is actually conditional on Windows.
Use the WIN32 symbol, which is defined by the MINGW32 and MSVC environments,
but not by Cygwin.
Define SNPRINTF_SIZE_CORR=1 for MSVC too, as its vsnprintf function does
not add NUL at the end of the buffer if the result fits the buffer size
exactly.
Signed-off-by: Frank Li <lznuaa@gmail.com>
Signed-off-by: Marius Storm-Olsen <mstormo@gmail.com>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lots of die() calls did not actually report the kind of error, which
can leave the user confused as to the real problem. Use die_errno()
where we check a system/library call that sets errno on failure, or
one of the following that wrap such calls:
Function Passes on error from
-------- --------------------
odb_pack_keep open
read_ancestry fopen
read_in_full xread
strbuf_read xread
strbuf_read_file open or strbuf_read_file
strbuf_readlink readlink
write_in_full xwrite
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change calls to die(..., strerror(errno)) to use the new die_errno().
In the process, also make slight style adjustments: at least state
_something_ about the function that failed (instead of just printing
the pathname), and put paths in single quotes.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes the behaviour of octal notation to how it is defined in the
documentation, while keeping the traditional "loosen only" semantics
intact for "group" and "everybody".
Three main points of this patch are:
- For an explicit octal notation, the internal shared_repository variable
is set to a negative value, so that we can tell "group" (which is to
"OR" in 0660) and 0660 (which is to "SET" to 0660);
- git-init did not set shared_repository variable early enough to affect
the initial creation of many files, notably copied templates and the
configuration. We set it very early when a command-line option
specifies a custom value.
- Many codepaths create files inside $GIT_DIR by various ways that all
involve mkstemp(), and then call move_temp_to_file() to rename it to
its final destination. We can add adjust_shared_perm() call here; for
the traditional "loosen-only", this would be a no-op for many codepaths
because the mode is already loose enough, but with the new behaviour it
makes a difference.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/maint-1.6.0-path-normalize:
Remove unused normalize_absolute_path()
Test and fix normalize_path_copy()
Fix GIT_CEILING_DIRECTORIES on Windows
Move sanitary_path_copy() to path.c and rename it to normalize_path_copy()
Make test-path-utils more robust against incorrect use
This function and normalize_absolute_path() do almost the same thing. The
former already works on Windows, but the latter crashes.
In subsequent changes we will remove normalize_absolute_path(). Here we
make the replacement function reusable. On the way we rename it to reflect
that it does some path normalization. Apart from that this is only moving
around code.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
