Bash Tweaks 1: git prompt

Joseph Violago — Mon, 13 Feb 2023 21:51:39 +0000

Originally posted on joev.me @ 2013-12-23

I can best describe my work environment in three words – git, bash & tabs. While it is important to have a basic level of competancy in bone-stock environments, I am also a firm believer in optimizing my workspace for the sake of comfort and productivity.

I mainly do my git fiddlin’ in bash console. Occasionally, I’ll use GitHub for investigating blames & history crawling. But my exposure & increased competence in git cli has taught me to appreciate a spruced up git config. Tour of my git toolbelt after the break.

Though bash is the core example of minimalist HUD (and simple is güd), I definately feel that a plain command prompt is too bare to productively manipulate & traverse branches.

I don’t know where I am (locally) compared to origin.

This problem really presents itself if/when my local HEAD has diverged from a merge conflict, working on out-of-date branches, or if a collaborator likes to push right before I do. (I’m looking at you, ~~Montero~~ (ﾉಥ益ಥ）ﾉ ┻━┻)

Solution(s)?

Option 1: $ git status my fingers numb (yeowch!)
Option 2: Configure a hotkey in .inputrc (more on that later…)
Option 3: Setup .bashrc to always show a mini git status

Here are some limitations to each though:

Excessive typing; finger fatigue…
Commands are now mapped to a hardware-specific input, which may not work when remoting in from another machine.
Some basic knowledge in shell scripting is required.

Today, Option 3.

Dependencies

Install git
Verify files or get them.
- /usr/lib/git-core/git-sh-prompt github
- /usr/share/bash-completion/completions/git github
If you see below, you’re good:

/etc/bash_completion.d/git-prompt

# In git versions < 1.7.12, this shell library was part of the
# git completion script.
#
# Some users rely on the __git_ps1 function becoming available
# when bash-completion is loaded.  Continue to load this library
# at bash-completion startup for now, to ease the transition to a
# world order where the prompt function is requested separately.
#
. /usr/lib/git-core/git-sh-prompt

Setup bashrc

Copy into ~/.bashrc

# Setup git autocompletion
if [ -f /usr/share/bash-completion/completions/git ]; then
  . /usr/share/bash-completion/completions/git
fi

# Setup git PS1 integration
if [ -f /usr/lib/git-core/git-sh-prompt ]; then
    . /usr/lib/git-core/git-sh-prompt
fi

GIT_PS1_SHOWCOLORHINTS      = "true"
GIT_PS1_SHOWUPSTREAM        = "verbose count git"
GIT_PS1_SHOWSTASHSTATE      = "1"
GIT_PS1_SHOWDIRTYSTATE      = "1"
GIT_PS1_SHOWUNTRACKEDFILES  = "1"

# Uncomment one of these
# no-color
# PS1='\u@\h:\w\n\d [\T]\n$(__git_ps1)\$ '
# color
# PS1='\[\033[32m\]\u@\h\[\033[00m\]:\[\033[34m\]\w\n\[\033[00m\]\d [\T]\n\[\033[31m\]$(__git_ps1)\[\033[00m\]\$ '

Apply changes to current terminal session:

$ . ~/.bashrc

Your bash prompt should now look like either of these:

  user@host:/home/user/git-path
    Mon Dec 23 [12:21:43]
    (master u=)$ _

    user@host:/home/user/git-path
    Mon Dec 23 [12:21:43]
    (master u=)$ _

And fin. Gone are the days of:

what branch am I on in this window?
(slam out more git status)

But kidding aside, this addition to my prompt has significantly cut down my frequency in calling git status. It is totally worth the minimal effort to implement.

Explained

That PS1 looks pretty cryptic, eh? Most of the script is mainly shell script. You can read more about tweaking bash prompt here. The secret sauce (and purpose of this post) is $(__git_ps1), which comes from /usr/lib/git-core/git-sh-prompt. If you’re itchy to customize, I invite you to read into the file to learn all about git_ps1’s different settings.

Written with StackEdit.

Octopress Plugins: s3_website

Joseph Violago — Mon, 13 Feb 2023 21:38:44 +0000

Originally posted on joev.me @ 2013-11-25

I’m hosted on S3 thanks to this blog post by Robert Brewitz. Do take a moment to read his post. My first swing at setup took me about a day to wrap my head around. After the next couple tries/tests, plugging-in jeckyl-s3 felt just as easy to slap together as octopress.

While browsing the jekyll-s3 repo, I found out that the project moved here. So I redid my octopress setup from scratch – which took < 5 min anyways (^_^). Upgrade impressions & comparisons after the break.

Luckily, Robert Brewitz’ tutorial was still mostly valid. So the config on _config.yml and s3 config did not need re-configuration. Huge time saver. Where the tutorial started to fall short where parts calling s3-jeckyl (obviously). The s3_website command is a bit different from jeckyl-s3, but there’s sufficient info in the README.md for you to figure it out.

Was it worth the upgrade?

Yes. Apart from more documentation, & logical commands, s3_website has also included (or, at least, made more apparent) additional features (routing, ). Overall, in the 7 months’ time that Robert Brewitz blogged about s3-jeckyl, the plugin/gem/watevs has evolved much more; into a well-packaged product.

Takeways

Don’t suck at s3 bucket nomenclature.

The only reason why I had as much trouble configuring jeckyl-s3 in the first place was because I was so stubborn in my desired routing. Don’t be stubborn. Follow the damn tute and be merry. ‘Nuff said.
Kinda wish I read a tutorial like this prior. (read: dd)
Add _site to .gitignore.

Do this for the same reason why public is in .gitignore – it’s generated markup, typically not intended to be edited.
Changing destination in _config.yml will break rake preview

This was fun… it took me months to realize this. I’m a noob at ruby. So now i keep destination stored like below and toggle the comment when pushing. Brilliant! pats self on back

...
destination: public   # default; rake preview
# destination: _site  # s3_website push
...

Welp, I hope this serves you well in your development of a slick deployment process. This was a good icebreaker exercise to get acquainted with octopress & jeckyl. I’ve been cruising on this high of slick tweaking and have been doing some work in the asides. But more on that later.