kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Øystein Walle	417abfde35	rev-parse: rev-parse: add --is-shallow-repository Running `git fetch --unshallow` on a repo that is not in fact shallow produces a fatal error message. Add a helper to rev-parse that scripters can use to determine whether a repo is shallow or not. Signed-off-by: Øystein Walle <oystwa@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Stefan Beller	bf0231c661	rev-parse: add --show-superproject-working-tree In some situations it is useful to know if the given repository is a submodule of another repository. Add the flag --show-superproject-working-tree to git-rev-parse to make it easy to find out if there is a superproject. When no superproject exists, the output will be empty. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Johannes Schindelin	098aa86762	rev-parse: fix several options when running in a subdirectory In addition to making git_path() aware of certain file names that need to be handled differently e.g. when running in worktrees, the commit `557bd833bb` (git_path(): be aware of file relocation in $GIT_DIR, 2014-11-30) also snuck in a new option for `git rev-parse`: `--git-path`. On the face of it, there is no obvious bug in that commit's diff: it faithfully calls git_path() on the argument and prints it out, i.e. `git rev-parse --git-path <filename>` has the same precise behavior as calling `git_path("<filename>")` in C. The problem lies deeper, much deeper. In hindsight (which is always unfair), implementing the .git/ directory discovery in `setup_git_directory()` by changing the working directory may have allowed us to avoid passing around a struct that contains information about the current repository, but it bought us many, many problems. In this case, when being called in a subdirectory, `git rev-parse` changes the working directory to the top-level directory before calling `git_path()`. In the new working directory, the result is correct. But in the working directory of the calling script, it is incorrect. Example: when calling `git rev-parse --git-path HEAD` in, say, the Documentation/ subdirectory of Git's own source code, the string `.git/HEAD` is printed. Side note: that bug is hidden when running in a subdirectory of a worktree that was added by the `git worktree` command: in that case, the (correct) absolute path of the `HEAD` file is printed. In the interest of time, this patch does not go the "correct" route to introduce a struct with repository information (and removing global state in the process), instead this patch chooses to detect when the command was called in a subdirectory and forces the result to be an absolute path. While at it, we are also fixing the output of --git-common-dir and --shared-index-path. Lastly, please note that we reuse the same strbuf for all of the relative_path() calls; this avoids frequent allocation (and duplicated code), and it does not risk memory leaks, for two reasons: 1) the cmd_rev_parse() function does not return anywhere between the use of the new strbuf instance and its final release, and 2) git-rev-parse is one of these "one-shot" programs in Git, i.e. it exits after running for a very short time, meaning that all allocated memory is released with the exit() call anyway. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Michael Rappazzo	5de8a549b4	rev-parse tests: add tests executed from a subdirectory t2027-worktree-list has an incorrect expectation for --git-common-dir which has been adjusted and marked to expect failure. Some of the tests added have been marked to expect failure. These demonstrate a problem with the way that some options to git rev-parse behave when executed from a subdirectory of the main worktree. [jes: fixed incorrect assumption that objects/ lives in the worktree-specific git-dir (it lives in the common dir instead). Also adjusted t1700 so that the test case does not need to be the last one in that script.] Signed-off-by: Michael Rappazzo <rappazzo@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
SZEDER Gábor	a2f5a87626	rev-parse: add '--absolute-git-dir' option The output of 'git rev-parse --git-dir' can be either a relative or an absolute path, depending on whether the current working directory is at the top of the worktree or the .git directory or not, or how the path to the repository is specified via the '--git-dir=<path>' option or the $GIT_DIR environment variable. And if that output is a relative path, then it is relative to the directory where any 'git -C <path>' options might have led us. This doesn't matter at all for regular scripts, because the git wrapper automatically takes care of changing directories according to the '-C <path>' options, and the scripts can then simply follow any path returned by 'git rev-parse --git-dir', even if it's a relative path. Our Bash completion script, however, is unique in that it must run directly in the user's interactive shell environment. This means that it's not executed through the git wrapper and would have to take care of any '-C <path> options on its own, and it can't just change directories as it pleases. Consequently, adding support for taking any '-C <path>' options on the command line into account during completion turned out to be considerably more difficult, error prone and required more subshells and git processes when it had to cope with a relative path to the .git directory. Help this rather special use case and teach 'git rev-parse' a new '--absolute-git-dir' option which always outputs a canonicalized absolute path to the .git directory, regardless of whether the path is discovered automatically or is specified via $GIT_DIR or 'git --git-dir=<path>'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	8 years ago
Eric Sunshine	e6273f4da5	t1500: avoid setting environment variables outside of tests Ideally, each test should be responsible for setting up state it needs rather than relying upon transient global state. Toward this end, teach test_rev_parse() to accept a "-g <dir>" option to allow callers to specify the value of the GIT_DIR environment variable explicitly. Take advantage of this new option to avoid polluting the global scope with GIT_DIR assignments. Implementation note: Typically, tests avoid polluting the global state by wrapping transient environment variable assignments within a subshell, however, this technique doesn't work here since test_config() and test_unconfig() need to know GIT_DIR, as well, but neither function can be used within a subshell. Consequently, GIT_DIR is instead cleared manually via test_when_finished(). Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Eric Sunshine	1dea0dc9e0	t1500: avoid setting configuration options outside of tests Ideally, each test should be responsible for setting up state it needs rather than relying upon transient global state. Toward this end, teach test_rev_parse() to accept a "-b <value>" option to allow callers to set "core.bare" explicitly or undefine it. Take advantage of this new option to avoid setting "core.bare" outside of tests. Under the hood, "-b <value>" invokes "test_config -C <dir>" (or "test_unconfig -C <dir>"), thus git-config knows explicitly where to find its configuration file. Consequently, the global GIT_CONFIG environment variable required by the manual git-config invocations outside of tests is no longer needed, and is thus dropped. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Eric Sunshine	1e043cff78	t1500: avoid changing working directory outside of tests Ideally, each test should be responsible for setting up state it needs rather than relying upon transient global state. Toward this end, teach test_rev_parse() to accept a "-C <dir>" option to allow callers to instruct it explicitly in which directory its tests should be run. Take advantage of this new option to avoid changing the working directory outside of tests. Implementation note: test_rev_parse() passes "-C <dir>" along to git-rev-parse with <dir> properly quoted. The natural and POSIX way to do so is via ${dir:+-C "$dir"}, however, with some older broken shells, this expression evaluates incorrectly to a single argument ("-C <dir>") rather than the expected two (-C and "<dir>"). Work around this problem with the slightly ungainly expression: ${dir:+-C} ${dir:+"$dir"} Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Eric Sunshine	12f7526c66	t1500: test_rev_parse: facilitate future test enhancements Tests run by test_rev_parse() are nearly identical; each invokes git-rev-parse with a single option and compares the result against an expected value. Such duplication makes it onerous to extend the tests since any change needs to be repeated in each test. Avoid the duplication by parameterizing the test and driving it via a for-loop. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Eric Sunshine	d66f68ff98	t1500: be considerate to future potential tests The final batch of git-rev-parse tests work against a non-local object database named repo.git. This is done by renaming .git to repo.git and pointing GIT_DIR at it, but the name is never restored to .git at the end of the script, which can be problematic for tests added in the future. Be more friendly by instead making repo.git a copy of .git. Furthermore, make it clear that tests in repo.git will be independent from the results of earlier tests done in .git by initializing repo.git earlier in the test sequence. Likewise, bundle remaining preparation (such as directory creation) into a common setup test consistent with modern practice. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
SZEDER Gábor	db7fee8758	t1500: more 'git rev-parse --git-dir' tests Extend t1500 with tests of 'git rev-parse --git-dir' when invoked from other directories of the repository or the work tree. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
SZEDER Gábor	8fb3c00d2e	Move 'rev-parse --git-dir' test to t1500 Commit `72183cb2` (Fix gitdir detection when in subdir of gitdir, 2009-01-16) added a test to 't1501-worktree' to check the behaviour of 'git rev-parse --git-dir' in a special case. However, t1501 is about testing separate work tree setups, and not about basic 'rev-parse' functionality, which is tested in t1500-rev-parse. Therefore, this patch moves that test to t1500. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Bryan Donlan	0e46e70462	Don't use the 'export NAME=value' in the test scripts. This form is not portable across all shells, so replace instances of: export FOO=bar with: FOO=bar export FOO Signed-off-by: Bryan Donlan <bdonlan@fushizen.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Jeff King	8bfa6bd647	fix config reading in tests Previously, we set the GIT_CONFIG environment variable in our tests so that only that file was read. However, setting it to a static value is not correct, since we are not necessarily always in the same directory; instead, we want the usual git config file lookup to happen. To do this, we stop setting GIT_CONFIG, which means that we must now suppress the reading of the system-wide and user configs. This exposes an incorrect test in t1500, which is also fixed (the incorrect test worked because we were failing to read the core.bare value from the config file, since the GIT_CONFIG variable was pointing us to the wrong file). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Johannes Schindelin	7efeb8f098	Reinstate the old behaviour when GIT_DIR is set and GIT_WORK_TREE is unset The old behaviour was to unilaterally default to the cwd is the work tree when GIT_DIR was set, but GIT_WORK_TREE wasn't, no matter if we are inside the GIT_DIR, or if GIT_DIR is actually something like ../../../.git. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Johannes Schindelin	e90fdc39b6	Clean up work-tree handling The old version of work-tree support was an unholy mess, barely readable, and not to the point. For example, why do you have to provide a worktree, when it is not used? As in "git status". Now it works. Another riddle was: if you can have work trees inside the git dir, why are some programs complaining that they need a work tree? IOW it is allowed to call $ git --git-dir=../ --work-tree=. bla when you really want to. In this case, you are both in the git directory and in the working tree. So, programs have to actually test for the right thing, namely if they are inside a working tree, and not if they are inside a git directory. Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was specified, unless there is a repository in the current working directory. It does now. The logic to determine if a repository is bare, or has a work tree (tertium non datur), is this: --work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true, which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR ends in /.git, which overrides the directory in which .git/ was found. In related news, a long standing bug was fixed: when in .git/bla/x.git/, which is a bare repository, git formerly assumed ../.. to be the appropriate git dir. This problem was reported by Shawn Pearce to have caused much pain, where a colleague mistakenly ran "git init" in "/" a long time ago, and bare repositories just would not work. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Matthias Lederhofer	6c56049ff6	extend rev-parse test for --is-inside-work-tree Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago
Matthias Lederhofer	dace6e44f6	test git rev-parse Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	18 years ago

19 Commits (ace64e56c10a61b184e1fcfc0dae34b4e78036de)