summaryrefslogtreecommitdiff
path: root/t/t1500-rev-parse.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-10-28rev-parse: add a --show-object-format optionLibravatar brian m. carlson1-0/+15
Add an option to print the object format used for input, output, or storage. This allows shell scripts to discover the hash algorithm in use. Since the transition plan allows for multiple input algorithms, document that we may provide multiple results for input, and the format that the results may take. While we don't support this now, documenting it early means that script authors can future-proof their scripts for when we do. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-28rev-parse: --show-superproject-working-tree should work during a mergeLibravatar Sam McKelvie1-0/+16
Invoking 'git rev-parse --show-superproject-working-tree' exits with "fatal: BUG: returned path string doesn't match cwd?" when the superproject has an unmerged entry for the current submodule, instead of displaying the superproject's working tree. The problem is due to the fact that when a merge of the submodule reference is in progress, "git ls-files --stage —full-name <submodule-relative-path>” returns three seperate entries for the submodule (one for each stage) rather than a single entry; e.g., $ git ls-files --stage --full-name submodule-child-test 160000 dbbd2766fa330fa741ea59bb38689fcc2d283ac5 1 submodule-child-test 160000 f174d1dbfe863a59692c3bdae730a36f2a788c51 2 submodule-child-test 160000 e6178f3a58b958543952e12824aa2106d560f21d 3 submodule-child-test The code in get_superproject_working_tree() expected exactly one entry to be returned; this patch makes it use the first entry if multiple entries are returned. Test t1500-rev-parse is extended to cover this case. Signed-off-by: Sam McKelvie <sammck@gmail.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-19rev-parse: rev-parse: add --is-shallow-repositoryLibravatar Øystein Walle1-0/+15
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>
2017-03-08rev-parse: add --show-superproject-working-treeLibravatar Stefan Beller1-0/+14
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>
2017-02-27Merge branch 'js/git-path-in-subdir'Libravatar Junio C Hamano1-0/+28
The "--git-path", "--git-common-dir", and "--shared-index-path" options of "git rev-parse" did not produce usable output. They are now updated to show the path to the correct file, relative to where the caller is. * js/git-path-in-subdir: rev-parse: fix several options when running in a subdirectory rev-parse tests: add tests executed from a subdirectory
2017-02-17rev-parse: fix several options when running in a subdirectoryLibravatar Johannes Schindelin1-2/+2
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>
2017-02-17rev-parse tests: add tests executed from a subdirectoryLibravatar Michael Rappazzo1-0/+28
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>
2017-02-03rev-parse: add '--absolute-git-dir' optionLibravatar SZEDER Gábor1-8/+9
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>
2016-05-18t1500: avoid setting environment variables outside of testsLibravatar Eric Sunshine1-9/+15
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>
2016-05-18t1500: avoid setting configuration options outside of testsLibravatar Eric Sunshine1-19/+20
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>
2016-05-18t1500: avoid changing working directory outside of testsLibravatar Eric Sunshine1-19/+23
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>
2016-05-18t1500: test_rev_parse: facilitate future test enhancementsLibravatar Eric Sunshine1-27/+17
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>
2016-05-17t1500: be considerate to future potential testsLibravatar Eric Sunshine1-3/+5
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>
2009-02-14t1500: more 'git rev-parse --git-dir' testsLibravatar SZEDER Gábor1-3/+3
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>
2009-02-14Move 'rev-parse --git-dir' test to t1500Libravatar SZEDER Gábor1-2/+9
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>
2008-05-05Don't use the 'export NAME=value' in the test scripts.Libravatar Bryan Donlan1-4/+5
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>
2008-02-06fix config reading in testsLibravatar Jeff King1-2/+2
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>
2007-08-10Reinstate the old behaviour when GIT_DIR is set and GIT_WORK_TREE is unsetLibravatar Johannes Schindelin1-2/+4
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>
2007-08-01Clean up work-tree handlingLibravatar Johannes Schindelin1-10/+10
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>
2007-06-06extend rev-parse test for --is-inside-work-treeLibravatar Matthias Lederhofer1-12/+17
Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06test git rev-parseLibravatar Matthias Lederhofer1-0/+72
Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>