summaryrefslogtreecommitdiff
path: root/t/t9903-bash-prompt.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-07-01git-prompt: improve cherry-pick/revert detectionLibravatar Phillip Wood1-2/+18
If the user commits or resets a conflict resolution in the middle of a sequence of cherry-picks or reverts then CHERRY_PICK_HEAD/REVERT_HEAD will be removed and so in the absence of those files we need to check .git/sequencer/todo to see if there is a cherry-pick or revert in progress. Signed-off-by: Phillip Wood <phillip.wood@dunelm.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-07rebase: implement --merge via the interactive machineryLibravatar Elijah Newren1-1/+1
As part of an ongoing effort to make rebase have more uniform behavior, modify the merge backend to behave like the interactive one, by re-implementing it on top of the latter. Interactive rebases are implemented in terms of cherry-pick rather than the merge-recursive builtin, but cherry-pick also calls into the recursive merge machinery by default and can accept special merge strategies and/or special strategy options. As such, there really is not any need for having both git-rebase--merge and git-rebase--interactive anymore. Delete git-rebase--merge.sh and instead implement it in builtin/rebase.c. This results in a few deliberate but small user-visible changes: * The progress output is modified (see t3406 and t3420 for examples) * A few known test failures are now fixed (see t3421) * bash-prompt during a rebase --merge is now REBASE-i instead of REBASE-m. Reason: The prompt is a reflection of the backend in use; this allows users to report an issue to the git mailing list with the appropriate backend information, and allows advanced users to know where to search for relevant control files. (see t9903) testcase modification notes: t3406: --interactive and --merge had slightly different progress output while running; adjust a test to match the new expectation t3420: these test precise output while running, but rebase--am, rebase--merge, and rebase--interactive all were built on very different commands (am, merge-recursive, cherry-pick), so the tests expected different output for each type. Now we expect --merge and --interactive to have the same output. t3421: --interactive fixes some bugs in --merge! Wahoo! t9903: --merge uses the interactive backend so the prompt expected is now REBASE-i. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'sg/test-must-be-empty'Libravatar Junio C Hamano1-4/+2
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'Libravatar SZEDER Gábor1-4/+2
Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-20Merge branch 'wc/make-funnynames-shared-lazy-prereq'Libravatar Junio C Hamano1-8/+5
A test prerequisite defined by various test scripts with slightly different semantics has been consolidated into a single copy and made into a lazily defined one. * wc/make-funnynames-shared-lazy-prereq: t: factor out FUNNYNAMES as shared lazy prereq
2018-08-06t: factor out FUNNYNAMES as shared lazy prereqLibravatar William Chargin1-8/+5
A fair number of tests need to check that the filesystem supports file names including "funny" characters, like newline, tab, and double-quote. Jonathan Nieder suggested that this be extracted into a lazy prereq in the top-level `test-lib.sh`. This patch effects that change. The FUNNYNAMES prereq now uniformly requires support for newlines, tabs, and double-quotes in filenames. This very slightly decreases the power of some tests, which might have run previously on a system that supports (e.g.) newlines and tabs but not double-quotes, but now will not. This seems to me like an acceptable tradeoff for consistency. One test (`t/t9902-completion.sh`) defined FUNNYNAMES to further require the separators \034 through \037, the test for which was implemented using the Bash-specific $'\034' syntax. I've elected to leave this one as is, renaming it to FUNNIERNAMES. After this patch, `git grep 'test_\(set\|lazy\)_prereq.*FUNNYNAMES'` has only one result. Signed-off-by: William Chargin <wchargin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16t9000-t9999: fix broken &&-chainsLibravatar Eric Sunshine1-1/+1
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-30t990X: use '.git/objects' as 'deep inside .git' pathLibravatar Christian Couder1-1/+1
Tests t9902-completion.sh and t9903-bash-prompt.sh each have tests that check what happens when we are "in the '.git' directory" and when we are "deep inside the '.git' directory". To test the case when we are "deep inside the '.git' directory" the test scripts used to perform a `cd .git/refs/heads`. As there are plans to implement other ref storage systems, let's use '.git/objects' instead of '.git/refs/heads' as the "deep inside the '.git' directory" path. This makes it clear to readers that these tests do not depend on which ref backend is used. The internals of the loose refs backend are still tested in t1400-update-ref.sh. Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-28t9903-bash-prompt: don't check the stderr of __git_ps1()Libravatar SZEDER Gábor1-12/+2
A test in 't9903-bash-prompt.sh' fails when the test script is run with '-x' tracing and a Bash version not yet supporting BASH_XTRACEFD, notably the default Bash version shipped in OSX. The reason for the failure is that the test checks the emptiness of __git_ps1()'s stderr, which includes the trace of all commands executed within __git_ps1() as well, throwing off the emptiness check. Having only a single test checking the empty stderr doesn't bring us much when none of the other tests do so, so remove this test for now. After this change t9903 passes with '-x', even when running with a Bash version not yet supporing BASH_XTRACEFD. In the future we might want to consider checking the emptiness of __git_ps1()'s stderr in each and every test, in which case we'd have to mark this test script as 'test_untraceable', but that's a different topic. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-07t9903: fix broken && chainLibravatar Johannes Sixt1-1/+1
We might wonder why our && chain check does not catch this case: The && chain check uses a strange exit code with the expectation that the second or later part of a broken && chain would not exit with this particular code. This expectation does not work in this case because __git_ps1, being the first command in the second part of the broken && chain, records the current exit code, does its work, and finally returns to the caller with the recorded exit code. This fools our && chain check. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-03Merge branch 'js/name-rev-use-oldest-ref'Libravatar Junio C Hamano1-1/+1
"git describe --contains" often made a hard-to-justify choice of tag to give name to a given commit, because it tried to come up with a name with smallest number of hops from a tag, causing an old commit whose close descendant that is recently tagged were not described with respect to an old tag but with a newer tag. It did not help that its computation of "hop" count was further tweaked to penalize being on a side branch of a merge. The logic has been updated to favor using the tag with the oldest tagger date, which is a lot easier to explain to the end users: "We describe a commit in terms of the (chronologically) oldest tag that contains the commit." * js/name-rev-use-oldest-ref: name-rev: include taggerdate in considering the best name
2016-04-22name-rev: include taggerdate in considering the best nameLibravatar Johannes Schindelin1-1/+1
We most likely want the oldest tag that contained the commit to be reported. So let's remember the taggerdate, and make it more important than anything else when choosing the best name for a given commit. Suggested by Linus Torvalds. Note that we need to update t9903 because it tested for the old behavior (which preferred the description "b1~1" over "tags/t2~1"). We might want to introduce a --heed-taggerdate option, and make the new behavior dependent on that, if it turns out that some scripts rely on the old name-rev method. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-28mingw: do not bother to test funny file namesLibravatar Johannes Schindelin1-1/+1
MSYS2 actually allows to create files or directories whose names contain tabs, newlines or colors, even if plain Win32 API cannot access them. As we are using an MSYS2 bash to run the tests, such files or directories are created successfully, but Git itself has no chance to work with them because it is a regular Windows program, hence limited by the Win32 API. With this change, on Windows otherwise failing tests in t3300-funny-names.sh, t3600-rm.sh, t3703-add-magic-pathspec.sh, t3902-quoted.sh, t4016-diff-quote.sh, t4135-apply-weird-filenames.sh, t9200-git-cvsexportcommit.sh, and t9903-bash-prompt.sh are skipped. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-24bash prompt: indicate dirty index even on orphan branchesLibravatar SZEDER Gábor1-2/+2
__git_ps1() doesn't indicate dirty index while on an orphan branch. To check the dirtiness of the index, __git_ps1() runs 'git diff-index --cached ... HEAD', which doesn't work on an orphan branch, because HEAD doesn't point to a valid commit. Run 'git diff ... --cached' instead, as it does the right thing both on valid and invalid HEAD, i.e. compares the index to the existing HEAD in the former case and to the empty tree in the latter. This fixes the two failing tests added in the first commit of this series. The dirtiness of the worktree is already checked with 'git diff' and is displayed correctly even on an orphan branch. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Jeff King <peff@peff.net>
2015-11-24bash prompt: test dirty index and worktree while on an orphan branchLibravatar SZEDER Gábor1-3/+28
There is only a single test exercising the dirty state indicator on an orphan branch, and in that test neither the index nor the worktree are dirty. Add two failing tests to check the dirty state indicator while either the index is dirty or while both the index and the worktree are dirty on an orphan branch, and to show that the dirtiness of the index is not displayed in these cases (the fourth combination, i.e. clean index and dirty worktree are impossible on an orphan branch). Update the existing dirty state indicator on clean orphan branch test to match the style of the two new tests, most importantly to use 'git checkout --orphan' instead of cd-ing into a repository that just happens to be empty and clean. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Jeff King <peff@peff.net>
2015-07-20bash prompt: test untracked files status indicator with untracked dirsLibravatar SZEDER Gábor1-0/+25
The next commit will tweak the way __git_ps1() decides whether to display the untracked files status indicator in the presence of untracked directories. Add tests to make sure it doesn't change current behavior, in particular that an empty untracked directory doesn't trigger the untracked files status indicator. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-26Merge branch 'jk/test-chain-lint'Libravatar Junio C Hamano1-1/+1
People often forget to chain the commands in their test together with &&, leaving a failure from an earlier command in the test go unnoticed. The new GIT_TEST_CHAIN_LINT mechanism allows you to catch such a mistake more easily. * jk/test-chain-lint: (36 commits) t9001: drop save_confirm helper t0020: use test_* helpers instead of hand-rolled messages t: simplify loop exit-code status variables t: fix some trivial cases of ignored exit codes in loops t7701: fix ignored exit code inside loop t3305: fix ignored exit code inside loop t0020: fix ignored exit code inside loops perf-lib: fix ignored exit code inside loop t6039: fix broken && chain t9158, t9161: fix broken &&-chain in git-svn tests t9104: fix test for following larger parents t4104: drop hand-rolled error reporting t0005: fix broken &&-chains t7004: fix embedded single-quotes t0050: appease --chain-lint t9001: use test_when_finished t4117: use modern test_* helpers t6034: use modern test_* helpers t1301: use modern test_* helpers t0020: use modern test_* helpers ...
2015-03-25Merge branch 'ct/prompt-untracked-fix'Libravatar Junio C Hamano1-0/+11
The prompt script (in contrib/) did not show the untracked sign when working in a subdirectory without any untracked files. * ct/prompt-untracked-fix: git prompt: use toplevel to find untracked files
2015-03-20t: fix trivial &&-chain breakageLibravatar Jeff King1-1/+1
These are tests which are missing a link in their &&-chain, but during a setup phase. We may fail to notice failure in commands that build the test environment, but these are typically not expected to fail at all (but it's still good to double-check that our test environment is what we expect). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-15git prompt: use toplevel to find untracked filesLibravatar Cody A Taylor1-0/+11
The __git_ps1() prompt function would not show an untracked state when all the untracked files are outside the current working directory. Signed-off-by: Cody A Taylor <codemister99@yahoo.com> Helped-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-01-07git-prompt.sh: allow to hide prompt for ignored pwdLibravatar Jess Austin1-0/+106
Optionally set __git_ps1 to display nothing when present working directory is ignored, triggered by the new environment variable GIT_PS1_HIDE_IF_PWD_IGNORED. This environment variable may be overridden on any repository by setting bash.hideIfPwdIgnored to "false". In the absence of GIT_PS1_HIDE_IF_PWD_IGNORED this change has no effect. Many people manage e.g. dotfiles in their home directory with git. This causes the prompt generated by __git_ps1 to refer to that "top level" repo while working in any descendant directory. That can be distracting, so this patch helps one shut off that noise. Signed-off-by: Jess Austin <jess.austin@gmail.com> Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19git-prompt.sh: don't assume the shell expands the value of PS1Libravatar Richard Hansen1-3/+3
Not all shells subject the prompt string to parameter expansion. Test whether the shell will expand the value of PS1, and use the result to control whether raw ref names are included directly in PS1. This fixes a regression introduced in commit 8976500 ("git-prompt.sh: don't put unsanitized branch names in $PS1"): zsh does not expand PS1 by default, but that commit assumed it did. The bug resulted in prompts containing the literal string '${__git_ps1_branch_name}' instead of the actual branch name. Reported-by: Caleb Thompson <caleb@calebthompson.io> Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-22git-prompt.sh: don't put unsanitized branch names in $PS1Libravatar Richard Hansen1-22/+22
Both bash and zsh subject the value of PS1 to parameter expansion, command substitution, and arithmetic expansion. Rather than include the raw, unescaped branch name in PS1 when running in two- or three-argument mode, construct PS1 to reference a variable that holds the branch name. Because the shells do not recursively expand, this avoids arbitrary code execution by specially-crafted branch names such as '$(IFS=_;cmd=sudo_rm_-rf_/;$cmd)'. Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-18bash prompt: test the prompt with newline in repository pathLibravatar SZEDER Gábor1-0/+23
Newlines in the path to a git repository were not an issue for the git-specific bash prompt before commit efaa0c1532 (bash prompt: combine 'git rev-parse' executions in the main code path, 2013-06-17), because the path returned by 'git rev-parse --git-dir' was directly stored in a variable, and this variable was later always accessed inside double quotes. Newlines are not an issue after commit efaa0c1532 either, but it's more subtle. Since efaa0c1532 we use the following single 'git rev-parse' execution to query various info about the repository: git rev-parse --git-dir --is-inside-git-dir \ --is-bare-repository --is-inside-work-tree The results to these queries are separated by a newline character in the output, e.g.: /home/szeder/src/git/.git false false true A newline in the path to the git repository could potentially break the parsing of these results and ultimately the bash prompt, unless the parsing is done right. Commit efaa0c1532 got it right, as I consciously started parsing 'git rev-parse's output from the end, where each record is a single line containing either 'true' or 'false' or, after e3e0b9378b (bash prompt: combine 'git rev-parse' for detached head, 2013-06-24), the abbreviated commit object name, and all what remains at the beginning is the path to the git repository, no matter how many lines it is. This subtlety really warrants its own test, especially since I didn't explain it in the log message or in an in-code comment back then, so add a test to excercise the prompt with newline characters in the path to the repository. Guard this test with the FUNNYNAMES prerequisite, because not all filesystems support newlines in filenames. Note that 'git rev-parse --git-dir' prints '.git' or '.' when at the top of the worktree or the repository, respectively, and only prints the full path to the repository when in a subdirectory, hence the need for changing into a subdir in the test. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-07-01Merge branch 'ed/color-prompt'Libravatar Junio C Hamano1-0/+141
Code clean-up for in-prompt status script (in contrib/). * ed/color-prompt: git-prompt.sh: add missing information in comments git-prompt.sh: do not print duplicate clean color code t9903: remove redundant tests git-prompt.sh: refactor colored prompt code t9903: add tests for git-prompt pcmode
2013-06-26git-prompt.sh: do not print duplicate clean color codeLibravatar Eduardo R. D'Avila1-4/+4
Do not print a duplicate clean color code when there is no other indicators other than the current branch in colored prompt. Acked-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Eduardo R. D'Avila <erdavila@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26t9903: remove redundant testsLibravatar Eduardo R. D'Avila1-114/+1
After refactoring __git_ps1_colorize_gitstring, codepaths for bash and zsh became mostly common and tests for bash and zsh became redundant. Remove tests for zsh. Keep one minimal test that stress the difference in codepaths for bash and zsh. Suggested-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Eduardo R. D'Avila <erdavila@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-26t9903: add tests for git-prompt pcmodeLibravatar Eduardo R. D'Avila1-0/+254
git-prompt.sh lacks tests for PROMPT_COMMAND mode. Add tests for: * pcmode prompt without colors * pcmode prompt with colors for bash * pcmode prompt with colors for zsh Having these tests enables an upcoming refactor in a safe way. Signed-off-by: Eduardo R. D'Avila <erdavila@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-24bash prompt: use bash builtins to check stash stateLibravatar SZEDER Gábor1-0/+1
When the environment variable $GIT_PS1_SHOWSTASHSTATE is set __git_ps1() checks the presence of stashes by running 'git rev-parse --verify refs/stash'. This command not only checks that the 'refs/stash' ref exists but also, well, verifies that it's a valid ref. However, we don't need to be that thorough for the bash prompt. We can omit that verification and only check whether 'refs/stash' exists or not. Since 'git pack-refs' never packs 'refs/stash', it's a matter of checking the existence of a ref file. Perform this check using only bash builtins to spare the overhead of fork()+exec()ing a git process. Also run 'git pack-refs --all' in the corresponding test to document that the prompt script depends on 'git pack-refs' not packing 'refs/stash' and to catch possible breakages should this behavior ever change. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
2013-06-24bash prompt: combine 'git rev-parse' for detached headLibravatar SZEDER Gábor1-0/+8
When describing a detached HEAD according to the $GIT_PS1_DESCRIBE environment variable fails, __git_ps1() now runs the '$(git rev-parse --short HEAD)' command substitution to get the abbreviated detached HEAD commit object name. This imposes the overhead of fork()ing a subshell and fork()+exec()ing a git process. Avoid this overhead by combining this command substitution with the "main" 'git rev-parse' execution for getting the path to the .git directory & co. This means that we'll look for the abbreviated commit object name even when it's not necessary, because we're on a branch or the detached HEAD can be described. It doesn't matter, however, because once 'git rev-parse' is up and running to fulfill all those other queries, the additional overhead of looking for the abbreviated commit object name is not measurable because it's lost in the noise. There is a caveat, however, when we are on an unborn branch, because in that case HEAD doesn't point to a valid commit, hence the query for the abbreviated commit object name fails. Therefore, '--short HEAD' must be the last options to 'git rev-parse' in order to get all the other necessary information for the prompt even on an unborn branch. Furthermore, in that case, and in that case only, 'git rev-parse' doesn't output the last line containing the abbreviated commit object name, obviously, so we have to take care to only parse it if 'git rev-parse' exited without any error. Although there are tests already excercising __git_ps1() on unborn branches, they all do so implicitly. Add a test that checks this explicitly. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
2013-06-24bash prompt: print unique detached HEAD abbreviated object nameLibravatar SZEDER Gábor1-1/+2
When describing a detached HEAD according to the $GIT_PS1_DESCRIBE environment variable fails, __git_ps1() runs 'cut -c1-7 .git/HEAD' to show the 7 hexdigits abbreviated commit object name in the prompt. Obviously, this neither respects core.abbrev nor produces a unique object name. Fix this by using 'git rev-parse --short HEAD' instead and adjust the corresponding test to use non-standard number of hexdigits. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
2013-06-24bash prompt: add a test for symbolic link symbolic refsLibravatar SZEDER Gábor1-0/+9
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
2013-06-24completion, bash prompt: move __gitdir() tests to completion test suiteLibravatar SZEDER Gábor1-128/+0
Currently __gitdir() is duplicated in the git completion and prompt scripts, while its tests are in the prompt test suite. This patch series is about to change __git_ps1() in a way that it won't need __gitdir() anymore and __gitdir() will be removed from the prompt script. So move all __gitdir() tests from the prompt test suite over to the completion test suite. Update the setup tests so that they perform only those steps that are necessary for each test suite. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
2013-06-24bash prompt: use 'write_script' helper in interactive rebase testLibravatar SZEDER Gábor1-7/+5
Helped-by: Jeff King <peff@peff.net> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
2013-06-24bash prompt: fix redirection coding style in testsLibravatar SZEDER Gábor1-116/+116
Use '>file' instead of '> file', in accordance with the coding guidelines. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
2013-05-29prompt: fix for simple rebaseLibravatar Felipe Contreras1-1/+1
When we are rebasing without options ('am' mode), the head rebased lives in '$g/rebase-apply/head-name', so lets use that information so it's reported the same way as if we were doing other rebases (-i or -m). Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-01Merge branch 'zk/prompt-rebase-step'Libravatar Junio C Hamano1-4/+10
* zk/prompt-rebase-step: bash-prompt.sh: show where rebase is at when stopped
2013-04-25bash-prompt.sh: show where rebase is at when stoppedLibravatar Zoltan Klinger1-4/+10
When a rebase stops (e.g. interrupted by a merge conflict), it could be useful to know how far a rebase has progressed and how many commits in total this rebase will apply. Teach the __git_ps1() command to display the number of commits so far applied and the total number of commits to be applied, like this: ((3ec0a6a...)|REBASE 2/5) In the example above the rebase has stopped at the second commit due to a merge conflict and there are a total number of five commits to be applied by this rebase. This information can be already obtained from the following files which are being generated during the rebase: GIT_DIR/.git/rebase-merge/msgnum (git-rebase--merge.sh) GIT_DIR/.git/rebase-merge/end (git-rebase--merge.sh) GIT_DIR/.git/rebase-apply/next (git-am.sh) GIT_DIR/.git/rebase-apply/last (git-am.sh) but "rebase -i" does not leave necessary clues. Implement this feature by doing these three things: 1) Modify git-rebase--interactive.sh to also create GIT_DIR/.git/rebase-merge/msgnum GIT_DIR/.git/rebase-merge/end files for the number of commits so far applied and the total number of commits to be applied. 2) Modify git-prompt.sh to read and display info from the above files. 3) Update test t9903-bash-prompt.sh to reflect changes introduced by this patch. Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-11t9903: Don't fail when run from path accessed through symlinkLibravatar Torstein Hegge1-5/+5
When the git directory is accessed through a symlink like ln -s /tmp/git /tmp/git-symlink cd /tmp/git-symlink/t make -C .. && ./t9903-bash-prompt.sh $TRASH_DIRECTORY is /tmp/git-symlink/t/trash directory.t9903-bash-prompt and $(pwd -P) is /tmp/git/t/trash directory.t9903-bash-prompt. When __gitdir looks up the path through 'git rev-parse --git-dir', it will return paths similar to $(pwd -P). This behavior is already tested in t9903 'gitdir - resulting path avoids symlinks'. Signed-off-by: Torstein Hegge <hegge@resisty.net> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-13t9903: add extra tests for bash.showDirtyStateLibravatar Martin Erik Werner1-1/+37
Add 3 extra tests for the bash.showDirtyState config option; the tests now cover all combinations of the shell var being set/unset and the config option being missing/enabled/disabled, given a dirty file. Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-13t9903: add tests for bash.showUntrackedFilesLibravatar Martin Erik Werner1-0/+40
Add 4 tests for the bash.showUntrackedFiles config option, covering all combinations of the shell var being set/unset and the config option being enabled/disabled (the other 2 cases, missing config with and without shell variable, are already covered by existing tests). Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-06-19completion: respect $GIT_DIRLibravatar SZEDER Gábor1-1/+9
The __gitdir() helper function finds out the path of the git repository by running 'git rev-parse --git-dir'. However, it has a shortcut first to avoid the overhead of running a git command in a subshell when the current directory is at the top of the work tree, i.e. when it contains a '.git' subdirectory. If the 'GIT_DIR' environment variable is set then it specifies the path to the git repository, and the autodetection of the '.git' directory is not necessary. However, $GIT_DIR is only taken into acocunt by 'git rev-parse --git-dir', and the check for the '.git' subdirectory is performed first, so it wins over the path given in $GIT_DIR. There are several completion (helper) functions that depend on __gitdir(), and when the above case triggers the completion script will do weird things, like offering refs, aliases, or stashes from a different repository, or displaying wrong or broken prompt, etc. So check first whether $GIT_DIR is set, and only proceed with checking the '.git' directory in the current directory if it isn't. 'git rev-parse' would also check whether the path in $GIT_DIR is a proper '.git' directory, i.e. 'HEAD', 'refs/', and 'objects/' are present and accessible, but we don't have to be that thorough for the bash prompt. And we've lived with an equally permissive check for '.git' in the current working directory for years anyway. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-22completion: split __git_ps1 into a separate scriptLibravatar Felipe Contreras1-1/+1
bash-completion 1.90 shipped with support to load completions dynamically[1], which means the git completion script wouldn't be loaded until the user types 'git <tab>'--this creates a problem to people using __git_ps1(); that function won't be available when the shell is first created. For now distributions have workarounded this issue by moving the git completion to the "compatdir"[2]; this of course is not ideal. The solution, proposed by Kerrick Staley[3], is to split the git script in two; the part that deals with __git_ps1() in one (i.e. git-prompt.sh), and everything else in another (i.e. git-completion.bash). Another benefit of this is that zsh user that are not interested in the bash completion can use it for their prompts, which has been tried before[4]. The only slight issue is that __gitdir() would be duplicated, but this is probably not a big deal. So let's go ahead and move __git_ps1() to a new file. While at this, I took the liberty to reformat the help text in the new file. [1] http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=99c4f7f25f50a7cb2fce86055bddfe389effa559 [2] http://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/git&id=974380fabb8f9f412990b17063bf578d98c44a82 [3] http://mid.gmane.org/CANaWP3w9KDu57aHquRRYt8td_haSWTBKs7zUHy-xu0B61gmr9A@mail.gmail.com [4] http://mid.gmane.org/1303824288-15591-1-git-send-email-mstormo@gmail.com Cc: Kerrick Staley <mail@kerrickstaley.com> Cc: Marius Storm-Olsen <mstormo@gmail.com> Cc: Ville Skyttä <ville.skytta@iki.fi> Cc: Dan McGee <dan@archlinux.org> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-09tests: add tests for the bash prompt functions in the completion scriptLibravatar SZEDER Gábor1-0/+448
The tests cover the discovery of the '.git' directory in the __gitdir() function in different scenarios, and the prompt itself, i.e. branch name, detached heads, operations (rebase, merge, cherry-pick, bisect), and status indicators (dirty, stash, untracked files; but not the upstream status). Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>