Giter Site home page Giter Site logo

git-info's Introduction

git-info

Exposes git repository status information to prompts.

Many thanks to Sorin Ionescu and Colin Hebert for the original code.

Settings

Ignore submodules

Retrieving the status of a repository with submodules can take a long time. So by default 'all' submodules are ignored. Optionally, 'untracked', 'dirty', or 'none' submodules can be ignored:

zstyle ':zim:git-info' ignore-submodules 'none'

Verbose mode

Verbose mode uses git status and computes the count of indexed, unindexed and also untracked files. Verbose mode can be slower, depending on your repository and the git version being used. It can be enabled with the following zstyle:

zstyle ':zim:git-info' verbose yes

In non-verbose mode, the untracked context is not available (see Main contexts below), and untracked files are also not considered for computing the dirty context.

Theming

To display information about the current repository in a prompt, use the following syntax to define custom styles for each context you want displayed:

zstyle ':zim:git-info:<context_name>' format '<string>'

Main contexts

Name Code Description
action %s Special action name (see Special action contexts below)
ahead %A Commits ahead of remote count
behind %B Commits behind remote count
diverged %V Diverged commits (both ahead and behind are yield when it's not defined)
branch %b Branch name
commit %c Commit short hash (when in 'detached HEAD' state)
clean %C Clean state
dirty %D Dirty state (count with untracked files when verbose mode enabled)
indexed %i Indexed files (count when verbose mode enabled)
unindexed %I Unindexed files (count when verbose mode enabled)
position %p Commits from nearest tag count (when in 'detached HEAD' state)
remote %R Remote name
stashed %S Stashed states count
untracked %u Untracked files count (only when verbose mode enabled)

While the commit and position contexts are only available when in 'detached HEAD' state, on the other hand, the ahead, behind, diverged, branch and remote contexts are only available when an actual branch is checked out (so when not in 'detached HEAD' state).

Special action contexts

Name Description Default value
action:rebase-i Rebase interactive rebase-i
action:rebase-m Rebase merge rebase-m
action:rebase Rebase rebase
action:am Apply mailbox am
action:am/rebase Apply mailbox or rebase am/rebase
action:merge Merge merge
action:revert-seq Revert sequence revert-seq
action:revert Revert revert
action:cherry-seq Cherry-pick sequence cherry-seq
action:cherry Cherry-pick cherry
action:bisect Bisect bisect

Formatting example for special actions:

zstyle ':zim:git-info:action:bisect' format '<B>'
zstyle ':zim:git-info:action:merge'  format '>M<'
zstyle ':zim:git-info:action:rebase' format '>R>'

Usage

First, customize the contexts you want displayed. For example, to format the branch name, commit, and remote name, define the following styles:

zstyle ':zim:git-info:branch' format 'branch:%b'
zstyle ':zim:git-info:commit' format 'commit:%c'
zstyle ':zim:git-info:remote' format 'remote:%R'

Second, define where the above contexts are displayed in prompts:

zstyle ':zim:git-info:keys' format \
    'prompt'  'git(%b%c)' \
    'rprompt' '[%R]'

Last, add ${(e)git_info[prompt]} and ${(e)git_info[rprompt]} to PS1 and RPS1 respectively, and add git-info to the precmd hooks.

Here's a complete example:

setopt nopromptbang prompt{cr,percent,sp,subst}

zstyle ':zim:git-info:branch' format 'branch:%b'
zstyle ':zim:git-info:commit' format 'commit:%c'
zstyle ':zim:git-info:remote' format 'remote:%R'

zstyle ':zim:git-info:keys' format \
    'prompt'  'git(%b%c)' \
    'rprompt' '[%R]'

autoload -Uz add-zsh-hook && add-zsh-hook precmd git-info

PS1='${(e)git_info[prompt]}%# '
RPS1='${(e)git_info[rprompt]}'

git-info's People

Contributors

ericbn avatar eriner avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

git-info's Issues

prompt hangs when verbose is enabled

  • I've checked the existing issues and I'm not duplicating a report.
  • I'm using the latest version of zimfw.
  • I've checked the Changelog and I'm not being affected by documented changes.
  • I've checked the 📢 Announcements and I'm not being affected by announced changes.
  • I was able to reproduce the issue with a clean installation of Zim.
  • I've pasted the output of zimfw info below.

Describe the bug
Shell hangs after executing a command inside a git repository, prompt is not shown

Steps to reproduce
The fist 4 steps restart the shell with a clean installation of Zim in a temporary directory.
Use exec zsh when restarting the terminal or restarting the shell is needed.

  1. cd ${$(mktemp -d):A}
  2. ZDOTDIR=${PWD} HOME=${PWD} ZIM_HOME=${PWD}/.zim exec zsh
  3. curl -fsSL https://raw.githubusercontent.com/zimfw/install/master/install.zsh | zsh
  4. exec zsh
  5. Use following config:
zstyle ':zim:git-info' verbose yes
zstyle ':zim:git-info:branch' format '%b'
zstyle ':zim:git-info:commit' format '%c'
zstyle ':zim:git-info:clean' format '%F{green}'
zstyle ':zim:git-info:dirty' format '%F{yellow}'
zstyle ':zim:git-info:keys' format 'prompt' ' %F{blue}git:(%F{cyan}%C%D%b%c%F{blue})%f'

Current behavior
Shell hangs after executing a command inside a git repository, prompt is not shown

Expected behavior
Prompt is shown

zimfw info

zimfw version: 1.9.1 (built at 2022-05-24 21:25:10 UTC, previous commit is 5bcfb8c)
ZIM_HOME:      /home/dmaes/.config/zim
Zsh version:   5.9
System info:   Linux inuits-t490 5.19.2-1-default #1 SMP PREEMPT_DYNAMIC Thu Aug 18 05:06:49 UTC 2022 (6c252ef) x86_64 x86_64 x86_64 GNU/Linux

Additional context
While debugging, it seems the problem lies with the asynchronously running of $cmds. Hanging happens when $cmds is empty. As much as adding a simple /bin/true to the $cmds array when in the if ! zstyle -t ':zim:git-info' verbose else-block fixes this.

Incompatibility with custom config setopt shwordsplit

Hi,

Here is an issue noticed during my move to zimfw (from a basic zsh, without any framework), when importing my existing zsh customizations.

  • I've checked the existing issues and I'm not duplicating a report.
  • I'm using the latest version of zimfw.
  • I've checked the Changelog and I'm not being affected by documented changes.
  • I've checked the 📢 Announcements and I'm not being affected by announced changes.
  • I was able to reproduce the issue with a clean installation of Zim.
  • I've pasted the output of zimfw info below.

Describe the bug
git-info doesn't work in a git directory, when using "setopt shwordsplit" (typically used in my .zshrc)

Steps to reproduce

  1. Go in a git directory
~
% cd .zim/modules/utility

~/.zim/modules/utility on master
% 
  1. set option shwordsplit
~/.zim/modules/utility on master
% setopt shwordsplit
git-info:zformat:232: invalid argument: %%B%F{magenta}%b%c%s${(e)git_info[status]:+"

~/.zim/modules/utility
%

=> error

  1. unset option shwordsplit
~/.zim/modules/utility
% unsetopt shwordsplit

~/.zim/modules/utility on master
%

=> no issue anymore

Current behavior
In step 2. we notice the error :
git-info:zformat:232: invalid argument: %%B%F{magenta}%b%c%s${(e)git_info[status]:+"

Expected behavior
Ideally, user configurations should not affect the behavior of Zim.

zimfw info

% zimfw info
zimfw version:        1.10.0 (built at 2022-09-27 22:44:10 UTC, previous commit is 05b8e0c)
OSTYPE:               linux-gnu
TERM:                 xterm-256color
TERM_PROGRAM:
TERM_PROGRAM_VERSION:
ZIM_HOME:             /tmp/tmp.FjTXshbGLs/.zim
ZSH_VERSION:          5.8.1

Additional context
Maybe this plugin (and also others) should use something like "emulate -L zsh" ?

According to man zshoptions :

       LOCAL_OPTIONS <K>
              If this option is set at the point of return from a shell  func‐
              tion, most options (including this one) which were in force upon
              entry to the function are restored; options  that  are  not  re‐
              stored  are PRIVILEGED and RESTRICTED.  Otherwise, only this op‐
              tion, and the LOCAL_LOOPS, XTRACE and  PRINT_EXIT_VALUE  options
              are  restored.   Hence  if  this  is explicitly unset by a shell
              function the other options in force at the point of return  will
              remain  so.   A shell function can also guarantee itself a known
              shell configuration with a formulation like  `emulate  -L  zsh';
              the -L activates LOCAL_OPTIONS.

Unless there is a way to do this in zimfw/zimfw rather than in each module.

Thanks

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.