For when I have to wrangle lots of files at once (like during interactive rebase to clean up history before push) I have a git watch alias that shows a high-level overview of changes that refreshes with inotify:
[alias]
watch = "!clear;inotifywait --quiet -mr -e modify,move,create,delete --format \"%f %e\" @/.git . | \
while read file; do \
clear;\
git status --short;\
git --no-pager diff --shortstat;\
done;"
I leave that running in a visible terminal window. It's more verbose than a prompt and reduces the need for constant git status sanity-checking. Maybe useful for someone.
I like my git prompt to show me my branch name, colored with grey (no changes), red (unsaved changes), or green (staged changes), with the depth of the branch, e.g.:
# I sometimes have very long branch names.
# I don't assume it's a hash:
if [ ${#GIT_BRANCH} -gt 40 ]; then
# GIT_BRANCH="(no branch)"
GIT_BRANCH="${GIT_BRANCH:0:40}..."
fi
and, at the end of `git_prompt`:
branch_depth=`git rev-list HEAD --not --remotes|wc -l`
echo "[$git_color$GIT_BRANCH$c_reset:${branch_depth}]"
This is neat and I think there's a lot of potential here. As with many information displays, though, it's critical to consider what the most important information to convey is and how to effectively do it.
My main question is around the use of color. I'd argue the error states - conflicts, diverging branches, etc - should be the ones in red, since those are the issues you want to call the most attention to.
Getting rid of any chartjunk is the other big thing. Using four characters of every prompt just for `git:` is not reasonable. And as much as I like the idea of being warned about untracked files, I fear that in most real situations you end up with random scratch files in the same directory. My prompt would always say `7A` at the end, wasting more space (and mental effort!).
Or should I be making these "pieces" like `git:(` and `)` configurable through args / env vars?
On the untracked files I personally never leave a file untracked. I either commit it or add it to .gitignore. Though I see how you use git differently, how about a --ignore-untracked to ignore untracked files?
Consider sending these changes upstream to contrib/completion/git-prompt.sh in git.git. It already has a lot of toggles for adjusting the prompt. These things you've added could be added as options.
I personally use the agnoster theme from oh-my-zsh. With the required powerline-patched font, its very readable and has enough git info to keep me informed without taking up too much space:
I like the appearance of prompts like this, and I've tried them a few times, but I always find myself turning them back off the first time I cd into a large git repository and have to wait a full second or two for the prompt to return. git is fast, but the prompt needs to show up instantly, and git isn't instantaneous on repositories the size of Linux or Chrome.
I use oh-my-git for a similar purpose. https://github.com/arialdomartini/oh-my-git Took some wrangling to get the fonts to work, but I find it to be quite helpful. The README is especially nice.
Push Git is great! I've been looking for a comparable solution for *nix for a while. Zsh's git completion/prompt just showing the branch and dirty state isn't enough.
You could negate the need for a --bash or --zsh flag by checking $SHELL:
echo $SHELL | egrep -o '[a-z]+$'
It might also make sense to bundle everything under one file as well. While I'd normally advocate separating code into smaller and more manageable files, a single file shell script would be more convenient to install and would require less disk reads per every prompt call.
Looks good though. I'm definitely going to use this on my dev boxes.
I added logic to mine to check for a .noprompt file and disable the git part of my bash prompt as I generally want it enabled, but a few large repos are too slow with it. You could do something similar, I'm sure.
[+] [-] an_ko|10 years ago|reply
For when I have to wrangle lots of files at once (like during interactive rebase to clean up history before push) I have a git watch alias that shows a high-level overview of changes that refreshes with inotify:
I leave that running in a visible terminal window. It's more verbose than a prompt and reduces the need for constant git status sanity-checking. Maybe useful for someone.[+] [-] gknoy|10 years ago|reply
I like my git prompt to show me my branch name, colored with grey (no changes), red (unsaved changes), or green (staged changes), with the depth of the branch, e.g.:
My prompt is based on: https://gist.github.com/tobiassjosten/828432... but I've made slight modifications:
and, at the end of `git_prompt`:[+] [-] an_ko|10 years ago|reply
[+] [-] TheRealWatson|10 years ago|reply
[+] [-] mendelk|10 years ago|reply
[+] [-] agumonkey|10 years ago|reply
[+] [-] metasean|10 years ago|reply
- Mikko Nylén's comment in http://web.archive.org/web/20130127054804/http://asemanfar.c...
- http://stackoverflow.com/questions/8120553/bash-profile-sett...
- http://volnitsky.com/project/git-prompt/
- http://misc.flogisoft.com/bash/tip_colors_and_formatting
- http://tldp.org/LDP/abs/html/string-manipulation.html
- http://www.botsko.net/blog/2010/03/16/git-status-in-command-...
[+] [-] couchand|10 years ago|reply
My main question is around the use of color. I'd argue the error states - conflicts, diverging branches, etc - should be the ones in red, since those are the issues you want to call the most attention to.
Getting rid of any chartjunk is the other big thing. Using four characters of every prompt just for `git:` is not reasonable. And as much as I like the idea of being warned about untracked files, I fear that in most real situations you end up with random scratch files in the same directory. My prompt would always say `7A` at the end, wasting more space (and mental effort!).
Good work!
[+] [-] michaelallen|10 years ago|reply
Fair point on the `git:(`, it's mostly a hold over from robbyrussells oh-my-zsh theme (which inspired me to make the first version of this about 2 years ago (https://github.com/michaeldfallen/oh-my-zsh/blob/master/them...).
The entire thing is composable so if you want a prompt without those bits just fork and modify: https://github.com/michaeldfallen/git-radar/blob/master/prom....
Or should I be making these "pieces" like `git:(` and `)` configurable through args / env vars?
On the untracked files I personally never leave a file untracked. I either commit it or add it to .gitignore. Though I see how you use git differently, how about a --ignore-untracked to ignore untracked files?
[+] [-] avar|10 years ago|reply
[+] [-] Walkman|10 years ago|reply
[1]: https://github.com/robbyrussell/oh-my-zsh
[2]: https://github.com/sorin-ionescu/prezto
[+] [-] Shebanator|10 years ago|reply
https://gist.github.com/agnoster/3712874
[+] [-] JoshTriplett|10 years ago|reply
[+] [-] anishathalye|10 years ago|reply
[+] [-] opsunit|10 years ago|reply
[+] [-] mallamanis|10 years ago|reply
[+] [-] noir_lord|10 years ago|reply
[+] [-] chmike|10 years ago|reply
[+] [-] lorenzfx|10 years ago|reply
[0] https://github.com/yonchu/zsh-vcs-prompt
[+] [-] oalders|10 years ago|reply
[+] [-] Shebanator|10 years ago|reply
[+] [-] chmike|10 years ago|reply
[+] [-] noalt|10 years ago|reply
[+] [-] devrelm|10 years ago|reply
[+] [-] laumars|10 years ago|reply
Looks good though. I'm definitely going to use this on my dev boxes.
[+] [-] michaelallen|10 years ago|reply
[+] [-] zerolinesofcode|10 years ago|reply
[+] [-] zvikara|10 years ago|reply
[+] [-] leni536|10 years ago|reply
https://github.com/xtrementl/dev-bash-git-ps1
I wonder if this one is any faster. Waiting for a bash prompt in large repos can be frustrating.
[+] [-] brandonwamboldt|10 years ago|reply
[+] [-] r3bl|10 years ago|reply
[+] [-] TsiCClawOfLight|10 years ago|reply
[+] [-] michaelallen|10 years ago|reply
[+] [-] toddchambery|10 years ago|reply
[+] [-] pwenzel|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] WorldWideWayne|10 years ago|reply