kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Richard Hansen	1e4119c81b	git-prompt.sh: don't assume the shell expands the value of PS1 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>	11 years ago
Richard Hansen	8976500cbb	git-prompt.sh: don't put unsanitized branch names in $PS1 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>	11 years ago
SZEDER Gábor	a4889e64bf	bash prompt: test the prompt with newline in repository path 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>	12 years ago
Eduardo R. D'Avila	15981f4eec	git-prompt.sh: do not print duplicate clean color code 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>	12 years ago
Eduardo R. D'Avila	f3bd62d02f	t9903: remove redundant tests 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>	12 years ago
Eduardo R. D'Avila	1572e18e60	t9903: add tests for git-prompt pcmode 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>	12 years ago
SZEDER Gábor	dd0b72cbd9	bash prompt: use bash builtins to check stash state 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>	12 years ago
SZEDER Gábor	e3e0b9378b	bash prompt: combine 'git rev-parse' for detached head 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>	12 years ago
SZEDER Gábor	e8f21caf94	bash prompt: print unique detached HEAD abbreviated object name 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>	12 years ago
SZEDER Gábor	868dc1acec	bash prompt: add a test for symbolic link symbolic refs Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>	12 years ago
SZEDER Gábor	c9a102e81f	completion, bash prompt: move __gitdir() tests to completion test suite 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>	12 years ago
SZEDER Gábor	7412290cc4	bash prompt: use 'write_script' helper in interactive rebase test Helped-by: Jeff King <peff@peff.net> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>	12 years ago
SZEDER Gábor	4fe00b4f0a	bash prompt: fix redirection coding style in tests Use '>file' instead of '> file', in accordance with the coding guidelines. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>	12 years ago
Felipe Contreras	1306321ebe	prompt: fix for simple rebase 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>	12 years ago
Zoltan Klinger	b71dc3e1a0	bash-prompt.sh: show where rebase is at when stopped 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>	12 years ago
Torstein Hegge	3ba40b45d8	t9903: Don't fail when run from path accessed through symlink 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>	12 years ago
Martin Erik Werner	dc7e7bced4	t9903: add extra tests for bash.showDirtyState 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>	12 years ago
Martin Erik Werner	58978e822c	t9903: add tests for bash.showUntrackedFiles 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>	12 years ago
SZEDER Gábor	b7be4366ea	completion: respect $GIT_DIR 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>	13 years ago
Felipe Contreras	af31a456b4	completion: split __git_ps1 into a separate script 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>	13 years ago
SZEDER Gábor	963c0407f4	tests: add tests for the bash prompt functions in the completion script 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>	13 years ago

23 Commits (6634f05454662b62e1f34766d3684b99fb53ad66)