summaryrefslogtreecommitdiffstats
path: root/contrib/completion/git-prompt.sh (follow)
Commit message (Collapse)AuthorAgeFilesLines
* completion: protect prompt against unset SHOWUPSTREAM in nounset modeVille Skyttä2024-04-011-1/+1
| | | | | | | | | | As it stands, the only call site of `__git_ps1_show_upstream` checks that the `GIT_PS1_SHOWUPSTREAM` variable is set, so this is effectively a no-op. However, that might change, and chances of noticing the unprotected use might not be that high when it does. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* completion: fix prompt with unset SHOWCONFLICTSTATE in nounset modeVille Skyttä2024-04-011-1/+1
| | | | | | | | | | `GIT_PS1_SHOWCONFLICTSTATE` is a user variable that might not be set, causing errors when the shell is in `nounset` mode. Take into account on access by falling back to an empty string. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: stop manually parsing HEAD with unknown ref formatsPatrick Steinhardt2024-01-081-7/+24
| | | | | | | | | | | | | | | | | | | | | | | | | We're manually parsing the HEAD reference in git-prompt to figure out whether it is a symbolic or direct reference. This makes it intimately tied to the on-disk format we use to store references and will stop working once we gain additional reference backends in the Git project. Ideally, we would refactor the code to exclusively use plumbing tools to read refs such that we do not have to care about the on-disk format at all. Unfortunately though, spawning processes can be quite expensive on some systems like Windows. As the Git prompt logic may be executed quite frequently we try very hard to spawn as few processes as possible. This refactoring is thus out of question for now. Instead, condition the logic on the repository's ref format: if the repo uses the the "files" backend we can continue to use the old logic and read the respective files from disk directly. If it's anything else, then we use git-symbolic-ref(1) to read the value of HEAD. This change makes the Git prompt compatible with the upcoming "reftable" format. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ek/completion-use-read-r-to-read-literally'Junio C Hamano2023-05-021-1/+1
|\ | | | | | | | | | | | | | | | | | | The completion script used to use bare "read" without the "-r" option to read the contents of various state files, which risked getting confused with backslashes in them. This has been corrected. * ek/completion-use-read-r-to-read-literally: completion: suppress unwanted unescaping of `read`
| * completion: suppress unwanted unescaping of `read`Edwin Kofler2023-04-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function `__git_eread`, which reads the first line from the file, calls the `read` builtin without passing the flag option `-r`. When the `read` builtin is called without the flag `-r`, it processes the backslash escaping in the text that it reads. For this reason, it is generally considered the best practice to always use the `read` builtin with flag `-r` unless one intensionally processes the backslash escaping. For the present case in git-prompt.sh, in fact, all the occurrences of the calls of `__git_eread` intend to read the literal content of the first lines. To make it read the first line literally, pass the flag `-r` to the `read` builtin in the function `__git_eread`. Signed-off-by: Edwin Kofler <edwin@kofler.dev> Signed-off-by: Koichi Murase <myoga.murase@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | completion: prompt: use generic colorsFelipe Contreras2023-03-161-12/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | | | When the prompt command mode was introduced in 1bfc51ac81 (Allow __git_ps1 to be used in PROMPT_COMMAND, 2012-10-10), the assumption was that it was necessary in order to properly add colors to PS1 in bash, but this wasn't true. It's true that the \[ \] markers add the information needed to properly calculate the width of the prompt, and they have to be added directly to PS1, a function returning them doesn't work. But that is because bash coverts the \[ \] markers in PS1 to \001 \002, which is what readline ultimately needs in order to calculate the width. We don't need bash to do this conversion, we can use \001 \002 ourselves, and then the prompt command mode is not necessary to display colors. This is what functions returning colors are supposed to do [1]. [1] http://mywiki.wooledge.org/BashFAQ/053 Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Tested-by: Joakim Petersen <joak-pet@online.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: show presence of unresolved conflicts at command promptJustin Donnelly2022-08-191-1/+11
| | | | | | | | | | | If GIT_PS1_SHOWCONFLICTSTATE is set to "yes", show the word "CONFLICT" on the command prompt when there are unresolved conflicts. Example prompt: (main|CONFLICT) Signed-off-by: Justin Donnelly <justinrdonnelly@gmail.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: fix expansion of branch colour codesJoakim Petersen2022-06-101-6/+6
| | | | | | | | | | | Because of the wrapping of the branch name variable $b, the colour codes in the variable don't get applied, but are instead printed directly in the output. Move the wrapping of $b to before colour codes are inserted to correct this. Revert move of branch name colour codes in tests, as the branch name is now coloured after the wrapping instead of before. Signed-off-by: Joakim Petersen <joak-pet@online.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: make colourization consistentJoakim Petersen2022-06-071-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The short upstream state indicator inherits the colour of the last short state indicator before it (if there is one), and the sparsity state indicator inherits this colour as well. This behaviour was introduced by 0ec7c23cdc6 (git-prompt: make upstream state indicator location consistent, 2022-02-27), while before this change the aforementioned indicators were white/the default text colour. Some examples to illustrate this behaviour (assuming all indicators are enabled and colourization is on): * If there is something in the stash, both the '$' and the short upstream state indicator following it will be blue. * If the local tree has new, untracked files and there is nothing in the stash, both the '%' and the short upstream state indicator will be red. * If all local changes are added to the index and the stash is empty, both the '+' and the short upstream state indicator following it will be green. * If the local tree is clean and there is nothing in the stash, the short upstream state indicator will be white/${default text colour}. This appears to be an unintended side-effect of the change, and makes little sense semantically (e.g. why is it bad to be in sync with upstream when you have uncommitted local changes?). The cause of the change in colourization is that previously, the short upstream state indicator appeared immediately after the rebase/revert/bisect/merge state indicator (note the position of $p in $gitstring): local f="$h$w$i$s$u" local gitstring="$c$b${f:+$z$f}${sparse}$r$p" Said indicator is prepended with the clear colour code, and the short upstream state indicator is thus also uncoloured. Now, the short upstream state indicator follows the sequence of colourized indicators, without any clearing of colour (again note the position of $p, now in $f): local f="$h$w$i$s$u$p" local gitstring="$c$b${f:+$z$f}${sparse}$r${upstream}" If the user is in a sparse checkout, the sparsity state indicator follows a similar pattern to the short upstream state indicator. However, clearing colour of the colourized indicators changes how the sparsity state indicator is colourized, as it currently inherits (and before the change referenced also inherited) the colour of the last short state indicator before it. Reading the commit message of the change that introduced the sparsity state indicator, afda36dbf3b (git-prompt: include sparsity state as well, 2020-06-21), it appears this colourization also was unintended, so clearing the colour for said indicator further increases consistency. Make the colourization of these state indicators consistent by making all colourized indicators clear their own colour. Make colouring of $c dependent on it not being empty, as it is no longer being used to colour the branch name. Move clearing of $b's prefix to before colourization so it gets cleared properly when colour codes are inserted into it. These changes make changing the layout of the prompt less prone to unintended colour changes in the future. Change coloured Bash prompt tests to reflect the colourization changes: * Move the colour codes to wrap the expected content of the expanded $__git_ps1_branch_name in all tests. * Insert a clear-colour code after the symbol for the first indicator in "prompt - bash color pc mode - dirty status indicator - dirty index and worktree", to reflect that all indicators should clear their own colour. Signed-off-by: Joakim Petersen <joak-pet@online.no> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: put upstream comments togetherJustin Donnelly2022-03-231-5/+5
| | | | | | | | | | | | | | | | Commit 6d158cba28 (bash completion: Support "divergence from upstream" messages in __git_ps1, 2010-06-17) introduced support for indicating divergence from upstream in the PS1 prompt. The comments at the top of git-prompt.sh that were introduced with that commit are several paragraphs long. Over the years, other comments have been inserted in between the paragraphs relating to divergence from upstream. This commit puts the comments relating to divergence from upstream back together. Signed-off-by: Justin Donnelly <justinrdonnelly@gmail.com> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: make long upstream state indicator consistentJustin Donnelly2022-03-231-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use a pipe as a separator before long upstream state indicator. This is consistent with long state indicators for sparse and in-progress operations (e.g. merge). For comparison, `__git_ps1` examples without upstream state indicator: (main) (main %) (main *%) (main|SPARSE) (main %|SPARSE) (main *%|SPARSE) (main|SPARSE|REBASE 1/2) (main %|SPARSE|REBASE 1/2) Note that if there are long state indicators, they appear after short state indicators if there are any, or after the branch name if there are no short state indicators. Each long state indicator begins with a pipe (`|`) as a separator. Before/after examples with long upstream state indicator: | Before | After | | ------------------------------- | ------------------------------- | | (main u=) | (main|u=) | | (main u= origin/main) | (main|u= origin/main) | | (main u+1) | (main|u+1) | | (main u+1 origin/main) | (main|u+1 origin/main) | | (main % u=) | (main %|u=) | | (main % u= origin/main) | (main %|u= origin/main) | | (main % u+1) | (main %|u+1) | | (main % u+1 origin/main) | (main %|u+1 origin/main) | | (main|SPARSE u=) | (main|SPARSE|u=) | | (main|SPARSE u= origin/main) | (main|SPARSE|u= origin/main) | | (main|SPARSE u+1) | (main|SPARSE|u+1) | | (main|SPARSE u+1 origin/main) | (main|SPARSE|u+1 origin/main) | | (main %|SPARSE u=) | (main %|SPARSE|u=) | | (main %|SPARSE u= origin/main) | (main %|SPARSE|u= origin/main) | | (main %|SPARSE u+1) | (main %|SPARSE|u+1) | | (main %|SPARSE u+1 origin/main) | (main %|SPARSE|u+1 origin/main) | Signed-off-by: Justin Donnelly <justinrdonnelly@gmail.com> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: make upstream state indicator location consistentJustin Donnelly2022-03-231-12/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make upstream state indicator location more consistent with similar state indicators (e.g. sparse). Group the short upstream state indicator (`=`, `<`, `>`, or `<>`) with other short state indicators immediately after the branch name. Previously short and long upstream state indicators appeared after all other state indicators. Use a separator (`SP` or `GIT_PS1_STATESEPARATOR`) between branch name and short upstream state indicator. Previously the short upstream state indicator would sometimes appear directly adjacent to the branch name instead of being separated. For comparison, `__git_ps1` examples without upstream state indicator: (main) (main %) (main *%) (main|SPARSE) (main %|SPARSE) (main *%|SPARSE) (main|SPARSE|REBASE 1/2) (main %|SPARSE|REBASE 1/2) Note that if there are short state indicators, they appear together after the branch name and separated from it by `SP` or `GIT_PS1_STATESEPARATOR`. Before/after examples with short upstream state indicator: | Before | After | | ---------------- | ---------------- | | (main=) | (main =) | | (main|SPARSE=) | (main =|SPARSE) | | (main %|SPARSE=) | (main %=|SPARSE) | Signed-off-by: Justin Donnelly <justinrdonnelly@gmail.com> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: rename `upstream` to `upstream_type`Justin Donnelly2022-03-231-13/+13
| | | | | | | | | | | In `__git_ps1_show_upstream` rename the variable `upstream` to `upstream_type`. This allows `__git_ps1_show_upstream` to reference a variable named `upstream` that is declared `local` in `__git_ps1`, which calls `__git_ps1_show_upstream`. Signed-off-by: Justin Donnelly <justinrdonnelly@gmail.com> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: work under set -uElijah Newren2021-05-131-3/+3
| | | | | | | | | | | Commit afda36dbf3 ("git-prompt: include sparsity state as well", 2020-06-21) added the use of some variables to control how to show sparsity state in the git prompt, but implicitly assumed that undefined variables would be treated as the empty string. This breaks users who run under 'set -u'; fix the code to be more explicit. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'sd/prompt-local-variable'Junio C Hamano2020-11-111-0/+1
|\ | | | | | | | | | | | | Code clean-up. * sd/prompt-local-variable: git-prompt.sh: localize `option` in __git_ps1_show_upstream
| * git-prompt.sh: localize `option` in __git_ps1_show_upstreamSibo Dong2020-11-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The variable 'option' is used in __git_ps1_show_upstream() without being localized. This clobbers the variable the user may be using for other purposes, which is bad. Luckily, $option is not used to carry information around in the script as a global variable. The use of it in this script has very limited scope (namely, only inside this function), so just declare that it is "local". Signed-off-by: Sibo Dong <sibo.dong@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | completion: prompt: fix color for ZshFelipe Contreras2020-10-281-4/+7
|/ | | | | | | | | | | | We don't need PROMPT_COMMAND in Zsh; we are already using %F{color} %f, which in turn use %{ and %}, which are the equivalent of Bash's \[ and \]. We can use as many colors as we want and output directly into PS1 (or RPS1) without the risk of buffer wrapping issues. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: change == to = for zsh's sakeDavid J. Malan2020-07-211-2/+2
| | | | | | | | | | | | | | When using git-prompt.sh with zsh, __git_ps1 currently errs when inside a repo with: __git_ps1:96: = not found Avoid using non-portable "==" that is only understood by bash and not zsh. Change to "=" so that the prompt script becomes usable with zsh again. Signed-off-by: David J. Malan <malan@harvard.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: include sparsity state as wellElijah Newren2020-06-221-2/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git-prompt includes the current branch, a bunch of single character mini-state displayers, and some much longer in-progress state notifications. The current branch is always shown. The single character mini-state displayers are all off by default (they are not self explanatory) but each has an environment variable for turning it on. The in-progress state notifications provide no configuration options for turning them off, and can be up to 15 characters long (e.g. "|REBASE (12/18)" or "|CHERRY-PICKING"). The single character mini-state tends to be used for things like "Do you have any stashes in refs/stash?" or "Are you ahead or behind of upstream?". These are things which users can take advantage of but do not affect most normal git operations. The in-progress states, by contrast, suggest the user needs to interact differently and may also prevent some normal operations from succeeding (e.g. git switch may show an error instead of switching branches). Sparsity is like the in-progress states in that it suggests a fundamental different interaction with the repository (many of the files from the repository are not present in your working copy!). A few commits ago added sparsity information to wt_longstatus_print_state(), grouping it with other in-progress state displays. We do similarly here with the prompt and show the extra state, by default, with an extra |SPARSE This state can be present simultaneously with the in-progress states, in which case it will appear before the other states; for example, (branchname|SPARSE|REBASE 6/10) The reason for showing the "|SPARSE" substring before other states is to emphasize those other states. Sparsity is probably not going to change much within a repository, while temporary operations will. So we want the state changes related to temporary operations to be listed last, to make them appear closer to where the user types and make them more likely to be noticed. The fact that sparsity isn't just cached metadata or additional information is what leads us to show it more similarly to the in-progress states, but the fact that sparsity is not transient like the in-progress states might cause some users to want an abbreviated notification of sparsity state or perhaps even be able to turn it off. Allow GIT_PS1_COMPRESSSPARSESTATE to be set to request that it be shortened to a single character ('?'), and GIT_PS1_OMITSPARSESTATE to be set to request that sparsity state be omitted from the prompt entirely. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: document how in-progress operations affect the promptElijah Newren2020-06-221-0/+4
| | | | | Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: change the prompt for interactive-based rebasesElijah Newren2020-02-171-5/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the past, we had different prompts for different types of rebases: REBASE: for am-based rebases REBASE-m: for merge-based rebases REBASE-i: for interactive-based rebases It's not clear why this distinction was necessary or helpful; when the prompt was added in commit e75201963f67 ("Improve bash prompt to detect various states like an unfinished merge", 2007-09-30), it simply added these three different types. Perhaps there was a useful purpose back then, but there have been some changes: * The merge backend was deleted after being implemented on top of the interactive backend, causing the prompt for merge-based rebases to change from REBASE-m to REBASE-i. * The interactive backend is used for multiple different types of non-interactive rebases, so the "-i" part of the prompt doesn't really mean what it used to. * Rebase backends have gained more abilities and have a great deal of overlap, sometimes making it hard to distinguish them. * Behavioral differences between the backends have also been ironed out. * We want to change the default backend from am to interactive, which means people would get "REBASE-i" by default if we didn't change the prompt, and only if they specified --am or --whitespace or -C would they get the "REBASE" prompt. * In the future, we plan to have "--whitespace", "-C", and even "--am" run the interactive backend once it can handle everything the am-backend can. For all these reasons, make the prompt for any type of rebase just be "REBASE". Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: improve cherry-pick/revert detectionPhillip Wood2019-07-011-4/+33
| | | | | | | | | | | 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>
* git-prompt: fix reading files with windows line endingsRobert Abel2017-12-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | If any of the files read by __git_eread have \r\n line endings, read will only strip \n, leaving \r. This results in an ugly prompt, where instead of user@pc MINGW64 /path/to/repo (BARE:master) the last parenthesis is printed over the beginning of the prompt like )ser@pc MINGW64 /path/to/repo (BARE:master This patch fixes the issue by changing the internal field separator variable IFS to $'\r\n' before using the read builtin command. Note that ANSI-C Quoting/POSIX Quoting ($'...') is supported by bash as well as zsh, which are the current targets of git-prompt, cf. contrib/completion/git-prompt.sh. Signed-off-by: Robert Abel <rabel@robertabel.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: make __git_eread intended use explicitRobert Abel2017-12-061-3/+4
| | | | | | | | | | | __git_eread is used to read a single line of a given file (if it exists) into a single variable stripping the EOL. This patch removes the unused capability to split file contents into tokens by passing multiple variable names. Add a comment and explicitly use $2 instead of misleading $@ as argument to the read builtin command. Signed-off-by: Robert Abel <rabel@robertabel.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-prompt: add a describe style for any tagsMichael J Gruber2017-03-151-0/+3
| | | | | | | | | | git-prompt has various describe styles, among them "describe" (by annotated tags) and "default" (by exact match with any tag). Add a mode "tag" that describes by any tag, annotated or not. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'vs/prompt-avoid-unset-variable'Junio C Hamano2016-06-271-3/+3
|\ | | | | | | | | | | | | | | The git-prompt scriptlet (in contrib/) was not friendly with those who uses "set -u", which has been fixed. * vs/prompt-avoid-unset-variable: git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION, $short_sha
| * git-prompt.sh: Don't error on null ${ZSH,BASH}_VERSION, $short_shaVille Skyttä2016-06-061-3/+3
| | | | | | | | | | | | | | | | | | When the shell is in "nounset" or "set -u" mode, referencing unset or null variables results in an error. Protect $ZSH_VERSION and $BASH_VERSION against that, and initialize $short_sha before use. Signed-off-by: Ville Skyttä <ville.skytta@iki.fi> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'jc/prompt-document-ps1-state-separator'Junio C Hamano2015-07-011-0/+4
| |\ | | | | | | | | | | | | | | | | | | Docfix. * jc/prompt-document-ps1-state-separator: git-prompt.sh: document GIT_PS1_STATESEPARATOR
* | | bash prompt: indicate dirty index even on orphan branchesSZEDER Gábor2015-11-241-3/+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>
* | | bash prompt: remove a redundant 'git diff' optionSZEDER Gábor2015-11-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | To get the dirty state indicator __git_ps1() runs 'git diff' with '--quiet --exit-code' options. '--quiet' already implies '--exit-code', so the latter is unnecessary and can be removed. Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Jeff King <peff@peff.net>
* | | bash prompt: faster untracked status indicator with untracked directoriesSZEDER Gábor2015-07-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the untracked status indicator is enabled, __git_ps1() looks for untracked files by running 'git ls-files'. This can be perceptibly slow in case of an untracked directory containing lot of files, because it lists all files found in the untracked directory only to be redirected into /dev/null right away (this is the actual command run by __git_ps1()): $ ls untracked-dir/ |wc -l 100000 $ time git ls-files --others --exclude-standard --error-unmatch \ -- ':/*' >/dev/null 2>/dev/null real 0m0.955s user 0m0.936s sys 0m0.016s Eliminate this delay by additionally passing the '--directory --no-empty-directory' options to 'git ls-files' to show only the name of non-empty untracked directories instead of all their content: $ time git ls-files --others --exclude-standard --directory \ --no-empty-directory --error-unmatch -- ':/*' >/dev/null 2>/dev/null real 0m0.010s user 0m0.008s sys 0m0.000s This follows suit of ea95c7b8f5 (completion: improve untracked directory filtering for filename completion, 2013-09-18). Signed-off-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/prompt-document-ps1-state-separator' into maintJunio C Hamano2015-07-151-0/+4
|\ \ \ | |/ / |/| / | |/ | | | | | | Docfix. * jc/prompt-document-ps1-state-separator: git-prompt.sh: document GIT_PS1_STATESEPARATOR
| * git-prompt.sh: document GIT_PS1_STATESEPARATORJoe Cridge2015-06-101-0/+4
| | | | | | | | | | | | | | | | | | | | | | The environment variable GIT_PS1_STATESEPARATOR can be used to set the separator between the branch name and the state symbols in the prompt. At present the variable is not mentioned in the inline documentation which makes it difficult for the casual user to identify. Signed-off-by: Joe Cridge <joe.cridge@me.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ct/prompt-untracked-fix'Junio C Hamano2015-03-251-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | 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
| * | git prompt: use toplevel to find untracked filesCody A Taylor2015-03-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'tf/prompt-preserve-exit-status'Junio C Hamano2015-01-141-5/+5
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Using the exit status of the last command in the prompt, e.g. PS1='$(__git_ps1) $? ', did not work well because the helper function stomped on the exit status. * tf/prompt-preserve-exit-status: git-prompt: preserve value of $? in all cases
| * | | git-prompt: preserve value of $? in all casesTony Finch2015-01-141-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Tony Finch <dot@dotat.at> Reviewed-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'rh/hide-prompt-in-ignored-directory'Junio C Hamano2015-01-141-7/+17
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | * rh/hide-prompt-in-ignored-directory: git-prompt.sh: allow to hide prompt for ignored pwd git-prompt.sh: if pc mode, immediately set PS1 to a plain prompt
| * | | | git-prompt.sh: allow to hide prompt for ignored pwdJess Austin2015-01-071-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * | | | git-prompt.sh: if pc mode, immediately set PS1 to a plain promptRichard Hansen2015-01-071-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At the beginning of __git_ps1, right after determining that the function is running in pc mode, set PS1 to a plain (undecorated) prompt. This makes it possible to simply return early without having to set PS1 if the prompt should not be decorated. Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | Merge branch 'tf/prompt-preserve-exit-status'Junio C Hamano2015-01-071-0/+4
|\ \ \ \ \ | |/ / / / |/| / / / | |/ / / | | | | | | | | | | | | | | | | | | | | Using the exit status of the last command in the prompt, e.g. PS1='$(__git_ps1) $? ', did not work well because the helper function stomped on the exit status. * tf/prompt-preserve-exit-status: git-prompt: preserve value of $? inside shell prompt
| * | | git-prompt: preserve value of $? inside shell promptTony Finch2014-12-221-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you have a prompt which displays the command exit status, __git_ps1 without this change corrupts it, although it has the correct value in the parent shell: ~/src/git (master) 0 $ set | grep ^PS1 PS1='\w$(__git_ps1) $? \$ ' ~/src/git (master) 0 $ false ~/src/git (master) 0 $ echo $? 1 ~/src/git (master) 0 $ There is a slightly ugly workaround: ~/src/git (master) 0 $ set | grep ^PS1 PS1='\w$(x=$?; __git_ps1; exit $x) $? \$ ' ~/src/git (master) 0 $ false ~/src/git (master) 1 $ This change makes the workaround unnecessary. Signed-off-by: Tony Finch <dot@dotat.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jg/prompt-localize-temporary'Junio C Hamano2014-12-221-1/+1
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | "git-prompt" (in contrib/) used a variable from the global scope, possibly contaminating end-user's namespace. * jg/prompt-localize-temporary: git-prompt.sh: make $f local to __git_eread()
| * | | git-prompt.sh: make $f local to __git_eread()Justin Guenther2014-12-131-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function uses (non-local) $f to store the value of its first parameter. This can interfere with the user's environment. Signed-off-by: Justin Guenther <jguenther@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | git-prompt: do not look for refs/stash in $GIT_DIRJeff King2014-08-251-1/+2
| |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since dd0b72c (bash prompt: use bash builtins to check stash state, 2011-04-01), git-prompt checks whether we have a stash by looking for $GIT_DIR/refs/stash. Generally external programs should never do this, because they would miss packed-refs. That commit claims that packed-refs does not pack refs/stash, but that is not quite true. It does pack the ref, but due to a bug, fails to prune the ref. When we fix that bug, we would want to be doing the right thing here. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname'Junio C Hamano2014-05-201-17/+39
|\ \ \ | | | | | | | | | | | | | | | | * rh/prompt-pcmode-avoid-eval-on-refname: git-prompt.sh: don't assume the shell expands the value of PS1
| * | | git-prompt.sh: don't assume the shell expands the value of PS1Richard Hansen2014-05-201-17/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | | Merge branch 'fc/prompt-zsh-read-from-file'Junio C Hamano2014-05-131-8/+8
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | * fc/prompt-zsh-read-from-file: contrib: completion: fix 'eread()' namespace
| * | | | contrib: completion: fix 'eread()' namespaceFelipe Contreras2014-05-131-8/+8
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise it might collide with a function of the same name in the user's environment. Suggested-by: SZEDER Gábor <szeder@ira.uka.de> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'rh/prompt-pcmode-avoid-eval-on-refname'Junio C Hamano2014-05-021-2/+32
|\ \ \ \ | |/ / / |/| / / | |/ / | | | * rh/prompt-pcmode-avoid-eval-on-refname: git-prompt.sh: don't put unsanitized branch names in $PS1
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-19 05:09:50 +0100