2012-05-22 20:46:40 +00:00
|
|
|
# bash/zsh git prompt support
|
|
|
|
#
|
|
|
|
# Copyright (C) 2006,2007 Shawn O. Pearce <spearce@spearce.org>
|
|
|
|
# Distributed under the GNU General Public License, version 2.0.
|
|
|
|
#
|
2013-06-26 03:05:17 +00:00
|
|
|
# This script allows you to see repository status in your prompt.
|
2012-05-22 20:46:40 +00:00
|
|
|
#
|
|
|
|
# To enable:
|
|
|
|
#
|
|
|
|
# 1) Copy this file to somewhere (e.g. ~/.git-prompt.sh).
|
|
|
|
# 2) Add the following line to your .bashrc/.zshrc:
|
|
|
|
# source ~/.git-prompt.sh
|
2012-12-11 23:04:36 +00:00
|
|
|
# 3a) Change your PS1 to call __git_ps1 as
|
2012-10-10 19:31:58 +00:00
|
|
|
# command-substitution:
|
|
|
|
# Bash: PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
|
2013-06-26 03:05:17 +00:00
|
|
|
# ZSH: setopt PROMPT_SUBST ; PS1='[%n@%m %c$(__git_ps1 " (%s)")]\$ '
|
2012-12-11 23:04:36 +00:00
|
|
|
# the optional argument will be used as format string.
|
2013-07-01 19:41:55 +00:00
|
|
|
# 3b) Alternatively, for a slightly faster prompt, __git_ps1 can
|
|
|
|
# be used for PROMPT_COMMAND in Bash or for precmd() in Zsh
|
bash prompt: mention that PROMPT_COMMAND mode is faster
__git_ps1() is usually added to the prompt inside a command
substitution, imposing the overhead of fork()ing a subshell. Using
__git_ps1() for $PROMPT_COMMAND is slightly faster, because it avoids
that command substitution.
Mention this in the comments about setting up the git prompt.
The whole series speeds up the bash prompt on Windows/MSysGit
considerably. Here are some timing results in three scenarios, each
repeated 10 times:
At the top of the work tree, before:
$ time for i in {0..9} ; do prompt="$(__git_ps1)" ; done
real 0m1.716s
user 0m0.301s
sys 0m0.772s
After:
real 0m0.687s
user 0m0.075s
sys 0m0.396s
After, from $PROMPT_COMMAND:
$ time for i in {0..9} ; do __git_ps1 '\h:\w' '$ ' ; done
real 0m0.546s
user 0m0.075s
sys 0m0.181s
At the top of the work tree, detached head, before:
real 0m2.574s
user 0m0.376s
sys 0m1.207s
After:
real 0m1.139s
user 0m0.151s
sys 0m0.500s
After, from $PROMPT_COMMAND:
real 0m1.030s
user 0m0.245s
sys 0m0.336s
In a subdirectory, during rebase, stash status indicator enabled,
before:
real 0m3.557s
user 0m0.495s
sys 0m1.767s
After:
real 0m0.717s
user 0m0.120s
sys 0m0.300s
After, from $PROMPT_COMMAND:
real 0m0.577s
user 0m0.047s
sys 0m0.258s
On Linux the speedup ratio is comparable to Windows, but overall it
was about an order of magnitude faster to begin with. The last case
from above, repeated 100 times, before:
$ time for i in {0..99} ; do prompt="$(__git_ps1)" ; done
real 0m2.806s
user 0m0.180s
sys 0m0.264s
After:
real 0m0.857s
user 0m0.020s
sys 0m0.028s
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
2013-06-24 00:28:02 +00:00
|
|
|
# with two parameters, <pre> and <post>, which are strings
|
|
|
|
# you would put in $PS1 before and after the status string
|
|
|
|
# generated by the git-prompt machinery. e.g.
|
2013-05-17 08:55:48 +00:00
|
|
|
# Bash: PROMPT_COMMAND='__git_ps1 "\u@\h:\w" "\\\$ "'
|
2013-06-26 03:05:17 +00:00
|
|
|
# will show username, at-sign, host, colon, cwd, then
|
|
|
|
# various status string, followed by dollar and SP, as
|
|
|
|
# your prompt.
|
2013-05-17 08:55:48 +00:00
|
|
|
# ZSH: precmd () { __git_ps1 "%n" ":%~$ " "|%s" }
|
2013-06-26 03:05:17 +00:00
|
|
|
# will show username, pipe, then various status string,
|
|
|
|
# followed by colon, cwd, dollar and SP, as your prompt.
|
2012-12-26 19:15:05 +00:00
|
|
|
# Optionally, you can supply a third argument with a printf
|
|
|
|
# format string to finetune the output of the branch status
|
2012-05-22 20:46:40 +00:00
|
|
|
#
|
2013-06-26 03:05:17 +00:00
|
|
|
# The repository status will be displayed only if you are currently in a
|
|
|
|
# git repository. The %s token is the placeholder for the shown status.
|
|
|
|
#
|
|
|
|
# The prompt status always includes the current branch name.
|
2012-05-22 20:46:40 +00:00
|
|
|
#
|
|
|
|
# In addition, if you set GIT_PS1_SHOWDIRTYSTATE to a nonempty value,
|
|
|
|
# unstaged (*) and staged (+) changes will be shown next to the branch
|
|
|
|
# name. You can configure this per-repository with the
|
|
|
|
# bash.showDirtyState variable, which defaults to true once
|
|
|
|
# GIT_PS1_SHOWDIRTYSTATE is enabled.
|
|
|
|
#
|
|
|
|
# You can also see if currently something is stashed, by setting
|
|
|
|
# GIT_PS1_SHOWSTASHSTATE to a nonempty value. If something is stashed,
|
|
|
|
# then a '$' will be shown next to the branch name.
|
|
|
|
#
|
|
|
|
# If you would like to see if there're untracked files, then you can set
|
|
|
|
# GIT_PS1_SHOWUNTRACKEDFILES to a nonempty value. If there're untracked
|
2013-02-13 11:01:58 +00:00
|
|
|
# files, then a '%' will be shown next to the branch name. You can
|
|
|
|
# configure this per-repository with the bash.showUntrackedFiles
|
|
|
|
# variable, which defaults to true once GIT_PS1_SHOWUNTRACKEDFILES is
|
|
|
|
# enabled.
|
2012-05-22 20:46:40 +00:00
|
|
|
#
|
|
|
|
# If you would like to see the difference between HEAD and its upstream,
|
|
|
|
# set GIT_PS1_SHOWUPSTREAM="auto". A "<" indicates you are behind, ">"
|
2012-09-24 17:41:26 +00:00
|
|
|
# indicates you are ahead, "<>" indicates you have diverged and "="
|
|
|
|
# indicates that there is no difference. You can further control
|
|
|
|
# behaviour by setting GIT_PS1_SHOWUPSTREAM to a space-separated list
|
|
|
|
# of values:
|
2012-05-22 20:46:40 +00:00
|
|
|
#
|
|
|
|
# verbose show number of commits ahead/behind (+/-) upstream
|
2013-10-10 14:40:39 +00:00
|
|
|
# name if verbose, then also show the upstream abbrev name
|
2012-05-22 20:46:40 +00:00
|
|
|
# legacy don't use the '--count' option available in recent
|
|
|
|
# versions of git-rev-list
|
|
|
|
# git always compare HEAD to @{upstream}
|
|
|
|
# svn always compare HEAD to your SVN upstream
|
|
|
|
#
|
2022-02-27 19:57:12 +00:00
|
|
|
# By default, __git_ps1 will compare HEAD to your SVN upstream if it can
|
|
|
|
# find one, or @{upstream} otherwise. Once you have set
|
|
|
|
# GIT_PS1_SHOWUPSTREAM, you can override it on a per-repository basis by
|
|
|
|
# setting the bash.showUpstream config variable.
|
|
|
|
#
|
2015-06-10 17:19:24 +00:00
|
|
|
# You can change the separator between the branch name and the above
|
|
|
|
# state symbols by setting GIT_PS1_STATESEPARATOR. The default separator
|
|
|
|
# is SP.
|
|
|
|
#
|
2020-06-21 05:21:26 +00:00
|
|
|
# When there is an in-progress operation such as a merge, rebase,
|
|
|
|
# revert, cherry-pick, or bisect, the prompt will include information
|
|
|
|
# related to the operation, often in the form "|<OPERATION-NAME>".
|
|
|
|
#
|
git-prompt: include sparsity state as well
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>
2020-06-21 05:21:27 +00:00
|
|
|
# When the repository has a sparse-checkout, a notification of the form
|
|
|
|
# "|SPARSE" will be included in the prompt. This can be shortened to a
|
|
|
|
# single '?' character by setting GIT_PS1_COMPRESSSPARSESTATE, or omitted
|
|
|
|
# by setting GIT_PS1_OMITSPARSESTATE.
|
|
|
|
#
|
2022-08-17 00:18:12 +00:00
|
|
|
# If you would like to see a notification on the prompt when there are
|
|
|
|
# unresolved conflicts, set GIT_PS1_SHOWCONFLICTSTATE to "yes". The
|
|
|
|
# prompt will include "|CONFLICT".
|
|
|
|
#
|
2012-12-11 23:20:24 +00:00
|
|
|
# If you would like to see more information about the identity of
|
|
|
|
# commits checked out as a detached HEAD, set GIT_PS1_DESCRIBE_STYLE
|
|
|
|
# to one of these values:
|
|
|
|
#
|
|
|
|
# contains relative to newer annotated tag (v1.6.3.2~35)
|
|
|
|
# branch relative to newer tag or branch (master~4)
|
|
|
|
# describe relative to older annotated tag (v1.6.3.1-13-gdd42c2f)
|
2017-03-15 13:15:09 +00:00
|
|
|
# tag relative to any older tag (v1.6.3.1-13-gdd42c2f)
|
2012-12-11 23:20:24 +00:00
|
|
|
# default exactly matching tag
|
2012-12-11 23:50:10 +00:00
|
|
|
#
|
2012-10-10 19:32:24 +00:00
|
|
|
# If you would like a colored hint about the current dirty state, set
|
2012-10-16 19:34:05 +00:00
|
|
|
# GIT_PS1_SHOWCOLORHINTS to a nonempty value. The colors are based on
|
2023-02-28 14:59:34 +00:00
|
|
|
# the colored output of "git status -sb".
|
2015-01-07 01:22:27 +00:00
|
|
|
#
|
|
|
|
# If you would like __git_ps1 to do nothing in the case when the current
|
|
|
|
# directory is set up to be ignored by git, then set
|
|
|
|
# GIT_PS1_HIDE_IF_PWD_IGNORED to a nonempty value. Override this on the
|
|
|
|
# repository level by setting bash.hideIfPwdIgnored to "false".
|
2012-05-22 20:46:40 +00:00
|
|
|
|
2013-08-22 01:39:03 +00:00
|
|
|
# check whether printf supports -v
|
|
|
|
__git_printf_supports_v=
|
|
|
|
printf -v __git_printf_supports_v -- '%s' yes >/dev/null 2>&1
|
|
|
|
|
2022-02-27 19:57:11 +00:00
|
|
|
# stores the divergence from upstream in $p
|
2012-05-22 20:46:40 +00:00
|
|
|
# used by GIT_PS1_SHOWUPSTREAM
|
|
|
|
__git_ps1_show_upstream ()
|
|
|
|
{
|
|
|
|
local key value
|
|
|
|
local svn_remote svn_url_pattern count n
|
2022-02-27 19:57:09 +00:00
|
|
|
local upstream_type=git legacy="" verbose="" name=""
|
2012-05-22 20:46:40 +00:00
|
|
|
|
|
|
|
svn_remote=()
|
|
|
|
# get some config options from git-config
|
|
|
|
local output="$(git config -z --get-regexp '^(svn-remote\..*\.url|bash\.showupstream)$' 2>/dev/null | tr '\0\n' '\n ')"
|
|
|
|
while read -r key value; do
|
|
|
|
case "$key" in
|
|
|
|
bash.showupstream)
|
|
|
|
GIT_PS1_SHOWUPSTREAM="$value"
|
|
|
|
if [[ -z "${GIT_PS1_SHOWUPSTREAM}" ]]; then
|
|
|
|
p=""
|
|
|
|
return
|
|
|
|
fi
|
|
|
|
;;
|
|
|
|
svn-remote.*.url)
|
2013-05-22 07:40:39 +00:00
|
|
|
svn_remote[$((${#svn_remote[@]} + 1))]="$value"
|
2013-10-15 12:21:11 +00:00
|
|
|
svn_url_pattern="$svn_url_pattern\\|$value"
|
2022-02-27 19:57:09 +00:00
|
|
|
upstream_type=svn+git # default upstream type is SVN if available, else git
|
2012-05-22 20:46:40 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
done <<< "$output"
|
|
|
|
|
|
|
|
# parse configuration values
|
2020-10-31 22:09:46 +00:00
|
|
|
local option
|
2012-05-22 20:46:40 +00:00
|
|
|
for option in ${GIT_PS1_SHOWUPSTREAM}; do
|
|
|
|
case "$option" in
|
2022-02-27 19:57:09 +00:00
|
|
|
git|svn) upstream_type="$option" ;;
|
2012-05-22 20:46:40 +00:00
|
|
|
verbose) verbose=1 ;;
|
|
|
|
legacy) legacy=1 ;;
|
2013-10-10 14:40:39 +00:00
|
|
|
name) name=1 ;;
|
2012-05-22 20:46:40 +00:00
|
|
|
esac
|
|
|
|
done
|
|
|
|
|
2022-02-27 19:57:09 +00:00
|
|
|
# Find our upstream type
|
|
|
|
case "$upstream_type" in
|
|
|
|
git) upstream_type="@{upstream}" ;;
|
2012-05-22 20:46:40 +00:00
|
|
|
svn*)
|
|
|
|
# get the upstream from the "git-svn-id: ..." in a commit message
|
|
|
|
# (git-svn uses essentially the same procedure internally)
|
2013-05-22 07:40:39 +00:00
|
|
|
local -a svn_upstream
|
|
|
|
svn_upstream=($(git log --first-parent -1 \
|
2012-05-22 20:46:40 +00:00
|
|
|
--grep="^git-svn-id: \(${svn_url_pattern#??}\)" 2>/dev/null))
|
|
|
|
if [[ 0 -ne ${#svn_upstream[@]} ]]; then
|
2013-05-22 07:40:39 +00:00
|
|
|
svn_upstream=${svn_upstream[${#svn_upstream[@]} - 2]}
|
2012-05-22 20:46:40 +00:00
|
|
|
svn_upstream=${svn_upstream%@*}
|
|
|
|
local n_stop="${#svn_remote[@]}"
|
|
|
|
for ((n=1; n <= n_stop; n++)); do
|
|
|
|
svn_upstream=${svn_upstream#${svn_remote[$n]}}
|
|
|
|
done
|
|
|
|
|
|
|
|
if [[ -z "$svn_upstream" ]]; then
|
|
|
|
# default branch name for checkouts with no layout:
|
2022-02-27 19:57:09 +00:00
|
|
|
upstream_type=${GIT_SVN_ID:-git-svn}
|
2012-05-22 20:46:40 +00:00
|
|
|
else
|
2022-02-27 19:57:09 +00:00
|
|
|
upstream_type=${svn_upstream#/}
|
2012-05-22 20:46:40 +00:00
|
|
|
fi
|
2022-02-27 19:57:09 +00:00
|
|
|
elif [[ "svn+git" = "$upstream_type" ]]; then
|
|
|
|
upstream_type="@{upstream}"
|
2012-05-22 20:46:40 +00:00
|
|
|
fi
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
# Find how many commits we are ahead/behind our upstream
|
|
|
|
if [[ -z "$legacy" ]]; then
|
|
|
|
count="$(git rev-list --count --left-right \
|
2022-02-27 19:57:09 +00:00
|
|
|
"$upstream_type"...HEAD 2>/dev/null)"
|
2012-05-22 20:46:40 +00:00
|
|
|
else
|
|
|
|
# produce equivalent output to --count for older versions of git
|
|
|
|
local commits
|
2022-02-27 19:57:09 +00:00
|
|
|
if commits="$(git rev-list --left-right "$upstream_type"...HEAD 2>/dev/null)"
|
2012-05-22 20:46:40 +00:00
|
|
|
then
|
|
|
|
local commit behind=0 ahead=0
|
|
|
|
for commit in $commits
|
|
|
|
do
|
|
|
|
case "$commit" in
|
|
|
|
"<"*) ((behind++)) ;;
|
|
|
|
*) ((ahead++)) ;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
count="$behind $ahead"
|
|
|
|
else
|
|
|
|
count=""
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
|
|
|
# calculate the result
|
|
|
|
if [[ -z "$verbose" ]]; then
|
|
|
|
case "$count" in
|
|
|
|
"") # no upstream
|
|
|
|
p="" ;;
|
|
|
|
"0 0") # equal to upstream
|
|
|
|
p="=" ;;
|
|
|
|
"0 "*) # ahead of upstream
|
|
|
|
p=">" ;;
|
|
|
|
*" 0") # behind upstream
|
|
|
|
p="<" ;;
|
|
|
|
*) # diverged from upstream
|
|
|
|
p="<>" ;;
|
|
|
|
esac
|
2022-02-27 19:57:10 +00:00
|
|
|
else # verbose, set upstream instead of p
|
2012-05-22 20:46:40 +00:00
|
|
|
case "$count" in
|
|
|
|
"") # no upstream
|
2022-02-27 19:57:10 +00:00
|
|
|
upstream="" ;;
|
2012-05-22 20:46:40 +00:00
|
|
|
"0 0") # equal to upstream
|
2022-02-27 19:57:11 +00:00
|
|
|
upstream="|u=" ;;
|
2012-05-22 20:46:40 +00:00
|
|
|
"0 "*) # ahead of upstream
|
2022-02-27 19:57:11 +00:00
|
|
|
upstream="|u+${count#0 }" ;;
|
2012-05-22 20:46:40 +00:00
|
|
|
*" 0") # behind upstream
|
2022-02-27 19:57:11 +00:00
|
|
|
upstream="|u-${count% 0}" ;;
|
2012-05-22 20:46:40 +00:00
|
|
|
*) # diverged from upstream
|
2022-02-27 19:57:11 +00:00
|
|
|
upstream="|u+${count#* }-${count% *}" ;;
|
2012-05-22 20:46:40 +00:00
|
|
|
esac
|
2013-10-10 14:40:39 +00:00
|
|
|
if [[ -n "$count" && -n "$name" ]]; then
|
2014-04-21 23:53:09 +00:00
|
|
|
__git_ps1_upstream_name=$(git rev-parse \
|
2022-02-27 19:57:09 +00:00
|
|
|
--abbrev-ref "$upstream_type" 2>/dev/null)
|
2014-05-19 22:55:37 +00:00
|
|
|
if [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then
|
2022-02-27 19:57:10 +00:00
|
|
|
upstream="$upstream \${__git_ps1_upstream_name}"
|
2014-04-21 23:53:09 +00:00
|
|
|
else
|
2022-02-27 19:57:10 +00:00
|
|
|
upstream="$upstream ${__git_ps1_upstream_name}"
|
2014-04-21 23:53:09 +00:00
|
|
|
# not needed anymore; keep user's
|
|
|
|
# environment clean
|
|
|
|
unset __git_ps1_upstream_name
|
|
|
|
fi
|
2013-10-10 14:40:39 +00:00
|
|
|
fi
|
2012-05-22 20:46:40 +00:00
|
|
|
fi
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2013-05-17 08:55:47 +00:00
|
|
|
# Helper function that is meant to be called from __git_ps1. It
|
2013-06-26 03:05:14 +00:00
|
|
|
# injects color codes into the appropriate gitstring variables used
|
git-prompt: make colourization consistent
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>
2022-06-07 11:50:24 +00:00
|
|
|
# to build a gitstring. Colored variables are responsible for clearing
|
|
|
|
# their own color.
|
2013-05-17 08:55:47 +00:00
|
|
|
__git_ps1_colorize_gitstring ()
|
|
|
|
{
|
2013-05-17 08:55:48 +00:00
|
|
|
if [[ -n ${ZSH_VERSION-} ]]; then
|
|
|
|
local c_red='%F{red}'
|
|
|
|
local c_green='%F{green}'
|
|
|
|
local c_lblue='%F{blue}'
|
|
|
|
local c_clear='%f'
|
2013-06-26 03:05:14 +00:00
|
|
|
else
|
2023-02-28 14:59:34 +00:00
|
|
|
# Using \001 and \002 around colors is necessary to prevent
|
2013-06-26 03:05:14 +00:00
|
|
|
# issues with command line editing/browsing/completion!
|
2023-02-28 14:59:34 +00:00
|
|
|
local c_red=$'\001\e[31m\002'
|
|
|
|
local c_green=$'\001\e[32m\002'
|
|
|
|
local c_lblue=$'\001\e[1;34m\002'
|
|
|
|
local c_clear=$'\001\e[0m\002'
|
2013-05-17 08:55:48 +00:00
|
|
|
fi
|
2013-05-17 08:55:47 +00:00
|
|
|
local bad_color=$c_red
|
|
|
|
local ok_color=$c_green
|
|
|
|
local flags_color="$c_lblue"
|
|
|
|
|
2013-06-26 03:05:14 +00:00
|
|
|
local branch_color=""
|
2013-05-17 08:55:47 +00:00
|
|
|
if [ $detached = no ]; then
|
|
|
|
branch_color="$ok_color"
|
|
|
|
else
|
|
|
|
branch_color="$bad_color"
|
|
|
|
fi
|
git-prompt: make colourization consistent
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>
2022-06-07 11:50:24 +00:00
|
|
|
if [ -n "$c" ]; then
|
|
|
|
c="$branch_color$c$c_clear"
|
|
|
|
fi
|
|
|
|
b="$branch_color$b$c_clear"
|
2013-05-17 08:55:47 +00:00
|
|
|
|
git-prompt: make colourization consistent
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>
2022-06-07 11:50:24 +00:00
|
|
|
if [ -n "$w" ]; then
|
|
|
|
w="$bad_color$w$c_clear"
|
2013-05-17 08:55:47 +00:00
|
|
|
fi
|
|
|
|
if [ -n "$i" ]; then
|
git-prompt: make colourization consistent
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>
2022-06-07 11:50:24 +00:00
|
|
|
i="$ok_color$i$c_clear"
|
2013-05-17 08:55:47 +00:00
|
|
|
fi
|
|
|
|
if [ -n "$s" ]; then
|
git-prompt: make colourization consistent
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>
2022-06-07 11:50:24 +00:00
|
|
|
s="$flags_color$s$c_clear"
|
2013-05-17 08:55:47 +00:00
|
|
|
fi
|
|
|
|
if [ -n "$u" ]; then
|
git-prompt: make colourization consistent
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>
2022-06-07 11:50:24 +00:00
|
|
|
u="$bad_color$u$c_clear"
|
2013-05-17 08:55:47 +00:00
|
|
|
fi
|
|
|
|
}
|
2012-05-22 20:46:40 +00:00
|
|
|
|
2017-12-05 23:39:11 +00:00
|
|
|
# Helper function to read the first line of a file into a variable.
|
|
|
|
# __git_eread requires 2 arguments, the file path and the name of the
|
|
|
|
# variable, in that order.
|
2014-05-13 13:21:19 +00:00
|
|
|
__git_eread ()
|
2014-04-11 23:32:25 +00:00
|
|
|
{
|
2023-04-20 22:38:00 +00:00
|
|
|
test -r "$1" && IFS=$'\r\n' read -r "$2" <"$1"
|
2014-04-11 23:32:25 +00:00
|
|
|
}
|
|
|
|
|
2019-07-01 14:21:06 +00:00
|
|
|
# see if a cherry-pick or revert is in progress, if the user has committed a
|
|
|
|
# conflict resolution with 'git commit' in the middle of a sequence of picks or
|
|
|
|
# reverts then CHERRY_PICK_HEAD/REVERT_HEAD will not exist so we have to read
|
|
|
|
# the todo file.
|
|
|
|
__git_sequencer_status ()
|
|
|
|
{
|
|
|
|
local todo
|
|
|
|
if test -f "$g/CHERRY_PICK_HEAD"
|
|
|
|
then
|
|
|
|
r="|CHERRY-PICKING"
|
|
|
|
return 0;
|
|
|
|
elif test -f "$g/REVERT_HEAD"
|
|
|
|
then
|
|
|
|
r="|REVERTING"
|
|
|
|
return 0;
|
|
|
|
elif __git_eread "$g/sequencer/todo" todo
|
|
|
|
then
|
|
|
|
case "$todo" in
|
|
|
|
p[\ \ ]|pick[\ \ ]*)
|
|
|
|
r="|CHERRY-PICKING"
|
|
|
|
return 0
|
|
|
|
;;
|
|
|
|
revert[\ \ ]*)
|
|
|
|
r="|REVERTING"
|
|
|
|
return 0
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
return 1
|
|
|
|
}
|
|
|
|
|
2012-05-22 20:46:40 +00:00
|
|
|
# __git_ps1 accepts 0 or 1 arguments (i.e., format string)
|
2012-10-10 19:31:58 +00:00
|
|
|
# when called from PS1 using command substitution
|
|
|
|
# in this mode it prints text to add to bash PS1 prompt (includes branch name)
|
|
|
|
#
|
2012-12-26 19:15:05 +00:00
|
|
|
# __git_ps1 requires 2 or 3 arguments when called from PROMPT_COMMAND (pc)
|
2012-10-10 19:31:58 +00:00
|
|
|
# in that case it _sets_ PS1. The arguments are parts of a PS1 string.
|
2012-12-26 19:15:05 +00:00
|
|
|
# when two arguments are given, the first is prepended and the second appended
|
2012-10-10 19:31:58 +00:00
|
|
|
# to the state string when assigned to PS1.
|
2012-12-26 19:15:05 +00:00
|
|
|
# The optional third parameter will be used as printf format string to further
|
|
|
|
# customize the output of the git-status string.
|
2012-10-10 19:32:24 +00:00
|
|
|
# In this mode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true
|
2012-05-22 20:46:40 +00:00
|
|
|
__git_ps1 ()
|
|
|
|
{
|
2015-01-14 10:06:28 +00:00
|
|
|
# preserve exit status
|
2014-12-22 18:09:25 +00:00
|
|
|
local exit=$?
|
2012-10-10 19:31:58 +00:00
|
|
|
local pcmode=no
|
2012-10-16 19:34:05 +00:00
|
|
|
local detached=no
|
2012-10-10 19:31:58 +00:00
|
|
|
local ps1pc_start='\u@\h:\w '
|
|
|
|
local ps1pc_end='\$ '
|
|
|
|
local printf_format=' (%s)'
|
|
|
|
|
|
|
|
case "$#" in
|
2012-12-26 19:15:05 +00:00
|
|
|
2|3) pcmode=yes
|
2012-10-10 19:31:58 +00:00
|
|
|
ps1pc_start="$1"
|
|
|
|
ps1pc_end="$2"
|
2012-12-26 19:15:05 +00:00
|
|
|
printf_format="${3:-$printf_format}"
|
2015-01-07 01:22:26 +00:00
|
|
|
# set PS1 to a plain prompt so that we can
|
|
|
|
# simply return early if the prompt should not
|
|
|
|
# be decorated
|
|
|
|
PS1="$ps1pc_start$ps1pc_end"
|
2012-10-10 19:31:58 +00:00
|
|
|
;;
|
|
|
|
0|1) printf_format="${1:-$printf_format}"
|
|
|
|
;;
|
2015-01-14 10:06:28 +00:00
|
|
|
*) return $exit
|
2012-10-10 19:31:58 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2014-05-19 22:55:37 +00:00
|
|
|
# ps1_expanded: This variable is set to 'yes' if the shell
|
|
|
|
# subjects the value of PS1 to parameter expansion:
|
|
|
|
#
|
|
|
|
# * bash does unless the promptvars option is disabled
|
|
|
|
# * zsh does not unless the PROMPT_SUBST option is set
|
|
|
|
# * POSIX shells always do
|
|
|
|
#
|
|
|
|
# If the shell would expand the contents of PS1 when drawing
|
|
|
|
# the prompt, a raw ref name must not be included in PS1.
|
|
|
|
# This protects the user from arbitrary code execution via
|
|
|
|
# specially crafted ref names. For example, a ref named
|
|
|
|
# 'refs/heads/$(IFS=_;cmd=sudo_rm_-rf_/;$cmd)' might cause the
|
|
|
|
# shell to execute 'sudo rm -rf /' when the prompt is drawn.
|
|
|
|
#
|
|
|
|
# Instead, the ref name should be placed in a separate global
|
|
|
|
# variable (in the __git_ps1_* namespace to avoid colliding
|
|
|
|
# with the user's environment) and that variable should be
|
|
|
|
# referenced from PS1. For example:
|
|
|
|
#
|
|
|
|
# __git_ps1_foo=$(do_something_to_get_ref_name)
|
|
|
|
# PS1="...stuff...\${__git_ps1_foo}...stuff..."
|
|
|
|
#
|
|
|
|
# If the shell does not expand the contents of PS1, the raw
|
|
|
|
# ref name must be included in PS1.
|
|
|
|
#
|
|
|
|
# The value of this variable is only relevant when in pcmode.
|
|
|
|
#
|
|
|
|
# Assume that the shell follows the POSIX specification and
|
|
|
|
# expands PS1 unless determined otherwise. (This is more
|
|
|
|
# likely to be correct if the user has a non-bash, non-zsh
|
|
|
|
# shell and safer than the alternative if the assumption is
|
|
|
|
# incorrect.)
|
|
|
|
#
|
|
|
|
local ps1_expanded=yes
|
2016-06-06 16:29:33 +00:00
|
|
|
[ -z "${ZSH_VERSION-}" ] || [[ -o PROMPT_SUBST ]] || ps1_expanded=no
|
|
|
|
[ -z "${BASH_VERSION-}" ] || shopt -q promptvars || ps1_expanded=no
|
2014-05-19 22:55:37 +00:00
|
|
|
|
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>
2013-06-24 00:16:02 +00:00
|
|
|
local repo_info rev_parse_exit_code
|
|
|
|
repo_info="$(git rev-parse --git-dir --is-inside-git-dir \
|
2024-01-04 08:21:53 +00:00
|
|
|
--is-bare-repository --is-inside-work-tree --show-ref-format \
|
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>
2013-06-24 00:16:02 +00:00
|
|
|
--short HEAD 2>/dev/null)"
|
|
|
|
rev_parse_exit_code="$?"
|
|
|
|
|
2013-06-17 20:58:42 +00:00
|
|
|
if [ -z "$repo_info" ]; then
|
2015-01-14 10:06:28 +00:00
|
|
|
return $exit
|
2011-09-05 18:53:37 +00:00
|
|
|
fi
|
|
|
|
|
2016-06-06 16:29:33 +00:00
|
|
|
local short_sha=""
|
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>
2013-06-24 00:16:02 +00:00
|
|
|
if [ "$rev_parse_exit_code" = "0" ]; then
|
|
|
|
short_sha="${repo_info##*$'\n'}"
|
|
|
|
repo_info="${repo_info%$'\n'*}"
|
|
|
|
fi
|
2024-01-04 08:21:53 +00:00
|
|
|
local ref_format="${repo_info##*$'\n'}"
|
|
|
|
repo_info="${repo_info%$'\n'*}"
|
2013-06-17 20:58:42 +00:00
|
|
|
local inside_worktree="${repo_info##*$'\n'}"
|
|
|
|
repo_info="${repo_info%$'\n'*}"
|
|
|
|
local bare_repo="${repo_info##*$'\n'}"
|
|
|
|
repo_info="${repo_info%$'\n'*}"
|
|
|
|
local inside_gitdir="${repo_info##*$'\n'}"
|
|
|
|
local g="${repo_info%$'\n'*}"
|
|
|
|
|
2015-01-07 01:22:27 +00:00
|
|
|
if [ "true" = "$inside_worktree" ] &&
|
|
|
|
[ -n "${GIT_PS1_HIDE_IF_PWD_IGNORED-}" ] &&
|
|
|
|
[ "$(git config --bool bash.hideIfPwdIgnored)" != "false" ] &&
|
|
|
|
git check-ignore -q .
|
|
|
|
then
|
2015-01-14 20:35:48 +00:00
|
|
|
return $exit
|
2015-01-07 01:22:27 +00:00
|
|
|
fi
|
|
|
|
|
git-prompt: include sparsity state as well
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>
2020-06-21 05:21:27 +00:00
|
|
|
local sparse=""
|
2021-05-13 06:22:36 +00:00
|
|
|
if [ -z "${GIT_PS1_COMPRESSSPARSESTATE-}" ] &&
|
|
|
|
[ -z "${GIT_PS1_OMITSPARSESTATE-}" ] &&
|
2020-07-21 00:15:31 +00:00
|
|
|
[ "$(git config --bool core.sparseCheckout)" = "true" ]; then
|
git-prompt: include sparsity state as well
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>
2020-06-21 05:21:27 +00:00
|
|
|
sparse="|SPARSE"
|
|
|
|
fi
|
|
|
|
|
2011-09-05 18:53:37 +00:00
|
|
|
local r=""
|
|
|
|
local b=""
|
|
|
|
local step=""
|
|
|
|
local total=""
|
|
|
|
if [ -d "$g/rebase-merge" ]; then
|
2014-05-13 13:21:19 +00:00
|
|
|
__git_eread "$g/rebase-merge/head-name" b
|
|
|
|
__git_eread "$g/rebase-merge/msgnum" step
|
|
|
|
__git_eread "$g/rebase-merge/end" total
|
git-prompt: change the prompt for interactive-based rebases
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>
2020-02-15 21:36:35 +00:00
|
|
|
r="|REBASE"
|
2012-10-10 19:31:58 +00:00
|
|
|
else
|
2011-09-05 18:53:37 +00:00
|
|
|
if [ -d "$g/rebase-apply" ]; then
|
2014-05-13 13:21:19 +00:00
|
|
|
__git_eread "$g/rebase-apply/next" step
|
|
|
|
__git_eread "$g/rebase-apply/last" total
|
2011-09-05 18:53:37 +00:00
|
|
|
if [ -f "$g/rebase-apply/rebasing" ]; then
|
2014-05-13 13:21:19 +00:00
|
|
|
__git_eread "$g/rebase-apply/head-name" b
|
2011-09-05 18:53:37 +00:00
|
|
|
r="|REBASE"
|
|
|
|
elif [ -f "$g/rebase-apply/applying" ]; then
|
|
|
|
r="|AM"
|
2013-04-25 09:28:54 +00:00
|
|
|
else
|
2011-09-05 18:53:37 +00:00
|
|
|
r="|AM/REBASE"
|
2012-05-22 20:46:40 +00:00
|
|
|
fi
|
2011-09-05 18:53:37 +00:00
|
|
|
elif [ -f "$g/MERGE_HEAD" ]; then
|
|
|
|
r="|MERGING"
|
2019-07-01 14:21:06 +00:00
|
|
|
elif __git_sequencer_status; then
|
|
|
|
:
|
2011-09-05 18:53:37 +00:00
|
|
|
elif [ -f "$g/BISECT_LOG" ]; then
|
|
|
|
r="|BISECTING"
|
|
|
|
fi
|
2012-05-22 20:46:40 +00:00
|
|
|
|
2011-03-31 21:41:18 +00:00
|
|
|
if [ -n "$b" ]; then
|
|
|
|
:
|
|
|
|
elif [ -h "$g/HEAD" ]; then
|
|
|
|
# symlink symbolic ref
|
|
|
|
b="$(git symbolic-ref HEAD 2>/dev/null)"
|
|
|
|
else
|
|
|
|
local head=""
|
2024-01-04 08:21:53 +00:00
|
|
|
|
|
|
|
case "$ref_format" in
|
|
|
|
files)
|
|
|
|
if ! __git_eread "$g/HEAD" head; then
|
|
|
|
return $exit
|
|
|
|
fi
|
|
|
|
|
|
|
|
if [[ $head == "ref: "* ]]; then
|
|
|
|
head="${head#ref: }"
|
|
|
|
else
|
|
|
|
head=""
|
|
|
|
fi
|
|
|
|
;;
|
|
|
|
*)
|
|
|
|
head="$(git symbolic-ref HEAD 2>/dev/null)"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
if test -z "$head"; then
|
2011-03-31 21:41:18 +00:00
|
|
|
detached=yes
|
|
|
|
b="$(
|
|
|
|
case "${GIT_PS1_DESCRIBE_STYLE-}" in
|
|
|
|
(contains)
|
|
|
|
git describe --contains HEAD ;;
|
|
|
|
(branch)
|
|
|
|
git describe --contains --all HEAD ;;
|
2017-03-15 13:15:09 +00:00
|
|
|
(tag)
|
|
|
|
git describe --tags HEAD ;;
|
2011-03-31 21:41:18 +00:00
|
|
|
(describe)
|
|
|
|
git describe HEAD ;;
|
|
|
|
(* | default)
|
|
|
|
git describe --tags --exact-match HEAD ;;
|
|
|
|
esac 2>/dev/null)" ||
|
2012-05-22 20:46:40 +00:00
|
|
|
|
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>
2013-06-24 00:16:02 +00:00
|
|
|
b="$short_sha..."
|
2011-03-31 21:41:18 +00:00
|
|
|
b="($b)"
|
2024-01-04 08:21:53 +00:00
|
|
|
else
|
|
|
|
b="$head"
|
2011-03-31 21:41:18 +00:00
|
|
|
fi
|
|
|
|
fi
|
2011-09-05 18:53:37 +00:00
|
|
|
fi
|
2012-05-22 20:46:40 +00:00
|
|
|
|
2011-09-05 18:53:37 +00:00
|
|
|
if [ -n "$step" ] && [ -n "$total" ]; then
|
|
|
|
r="$r $step/$total"
|
|
|
|
fi
|
2013-04-25 09:28:54 +00:00
|
|
|
|
2022-08-17 00:18:12 +00:00
|
|
|
local conflict="" # state indicator for unresolved conflicts
|
|
|
|
if [[ "${GIT_PS1_SHOWCONFLICTSTATE}" == "yes" ]] &&
|
|
|
|
[[ $(git ls-files --unmerged 2>/dev/null) ]]; then
|
|
|
|
conflict="|CONFLICT"
|
|
|
|
fi
|
|
|
|
|
2011-09-05 18:53:37 +00:00
|
|
|
local w=""
|
|
|
|
local i=""
|
|
|
|
local s=""
|
|
|
|
local u=""
|
git-prompt: include sparsity state as well
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>
2020-06-21 05:21:27 +00:00
|
|
|
local h=""
|
2011-09-05 18:53:37 +00:00
|
|
|
local c=""
|
2022-02-27 19:57:10 +00:00
|
|
|
local p="" # short version of upstream state indicator
|
|
|
|
local upstream="" # verbose version of upstream state indicator
|
2012-05-22 20:46:40 +00:00
|
|
|
|
2013-06-17 20:58:42 +00:00
|
|
|
if [ "true" = "$inside_gitdir" ]; then
|
|
|
|
if [ "true" = "$bare_repo" ]; then
|
2011-09-05 18:53:37 +00:00
|
|
|
c="BARE:"
|
|
|
|
else
|
|
|
|
b="GIT_DIR!"
|
|
|
|
fi
|
2013-06-17 20:58:42 +00:00
|
|
|
elif [ "true" = "$inside_worktree" ]; then
|
2011-09-05 18:53:37 +00:00
|
|
|
if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ] &&
|
|
|
|
[ "$(git config --bool bash.showDirtyState)" != "false" ]
|
|
|
|
then
|
2015-11-21 14:46:40 +00:00
|
|
|
git diff --no-ext-diff --quiet || w="*"
|
2015-11-21 11:30:09 +00:00
|
|
|
git diff --no-ext-diff --cached --quiet || i="+"
|
|
|
|
if [ -z "$short_sha" ] && [ -z "$i" ]; then
|
2011-09-05 18:53:37 +00:00
|
|
|
i="#"
|
2012-05-22 20:46:40 +00:00
|
|
|
fi
|
2011-09-05 18:53:37 +00:00
|
|
|
fi
|
2011-04-01 15:47:37 +00:00
|
|
|
if [ -n "${GIT_PS1_SHOWSTASHSTATE-}" ] &&
|
2014-08-23 05:26:51 +00:00
|
|
|
git rev-parse --verify --quiet refs/stash >/dev/null
|
|
|
|
then
|
2011-04-01 15:47:37 +00:00
|
|
|
s="$"
|
2011-09-05 18:53:37 +00:00
|
|
|
fi
|
2012-05-22 20:46:40 +00:00
|
|
|
|
2011-09-05 18:53:37 +00:00
|
|
|
if [ -n "${GIT_PS1_SHOWUNTRACKEDFILES-}" ] &&
|
|
|
|
[ "$(git config --bool bash.showUntrackedFiles)" != "false" ] &&
|
2015-07-19 11:28:06 +00:00
|
|
|
git ls-files --others --exclude-standard --directory --no-empty-directory --error-unmatch -- ':/*' >/dev/null 2>/dev/null
|
2011-09-05 18:53:37 +00:00
|
|
|
then
|
|
|
|
u="%${ZSH_VERSION+%}"
|
|
|
|
fi
|
2012-05-22 20:46:40 +00:00
|
|
|
|
2021-05-13 06:22:36 +00:00
|
|
|
if [ -n "${GIT_PS1_COMPRESSSPARSESTATE-}" ] &&
|
2020-07-21 00:15:31 +00:00
|
|
|
[ "$(git config --bool core.sparseCheckout)" = "true" ]; then
|
git-prompt: include sparsity state as well
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>
2020-06-21 05:21:27 +00:00
|
|
|
h="?"
|
|
|
|
fi
|
|
|
|
|
2011-09-05 18:53:37 +00:00
|
|
|
if [ -n "${GIT_PS1_SHOWUPSTREAM-}" ]; then
|
|
|
|
__git_ps1_show_upstream
|
2012-05-22 20:46:40 +00:00
|
|
|
fi
|
2011-09-05 18:53:37 +00:00
|
|
|
fi
|
2012-05-22 20:46:40 +00:00
|
|
|
|
2011-09-05 18:53:37 +00:00
|
|
|
local z="${GIT_PS1_STATESEPARATOR-" "}"
|
2013-06-26 03:05:14 +00:00
|
|
|
|
2022-06-10 00:47:37 +00:00
|
|
|
b=${b##refs/heads/}
|
|
|
|
if [ $pcmode = yes ] && [ $ps1_expanded = yes ]; then
|
|
|
|
__git_ps1_branch_name=$b
|
|
|
|
b="\${__git_ps1_branch_name}"
|
|
|
|
fi
|
|
|
|
|
2020-10-28 02:06:50 +00:00
|
|
|
if [ -n "${GIT_PS1_SHOWCOLORHINTS-}" ]; then
|
2023-02-28 14:59:34 +00:00
|
|
|
__git_ps1_colorize_gitstring
|
2013-07-01 19:41:55 +00:00
|
|
|
fi
|
2013-06-26 03:05:14 +00:00
|
|
|
|
2022-02-27 19:57:10 +00:00
|
|
|
local f="$h$w$i$s$u$p"
|
2022-08-17 00:18:12 +00:00
|
|
|
local gitstring="$c$b${f:+$z$f}${sparse}$r${upstream}${conflict}"
|
2013-06-26 03:05:14 +00:00
|
|
|
|
2011-09-05 18:53:37 +00:00
|
|
|
if [ $pcmode = yes ]; then
|
2013-08-22 01:39:03 +00:00
|
|
|
if [ "${__git_printf_supports_v-}" != yes ]; then
|
2013-06-17 19:42:55 +00:00
|
|
|
gitstring=$(printf -- "$printf_format" "$gitstring")
|
|
|
|
else
|
|
|
|
printf -v gitstring -- "$printf_format" "$gitstring"
|
|
|
|
fi
|
2011-09-05 18:53:37 +00:00
|
|
|
PS1="$ps1pc_start$gitstring$ps1pc_end"
|
|
|
|
else
|
2013-07-01 19:41:55 +00:00
|
|
|
printf -- "$printf_format" "$gitstring"
|
2012-05-22 20:46:40 +00:00
|
|
|
fi
|
2014-12-22 18:09:25 +00:00
|
|
|
|
|
|
|
return $exit
|
2012-05-22 20:46:40 +00:00
|
|
|
}
|