Dariusz on Software Quality & Performance

03/01/2015

Couring GIT output

Filed under: en — Tags: — dariusz.cieslak @

Default git colour setup is not so good. On black terminal background it looks dark:

297

However, with small change in ~/.git/config file:

[color "diff"]
meta = yellow bold
frag = magenta bold
old = red bold
new = green bold

you would get much better diff display on your terminal:

298

27/08/2013

Git local stashes minimal browser

Filed under: en — Tags: — dariusz.cieslak @

Stash mechanism (sometimes it's called "shelve" – in bazaar for example) is responsible for holding your local changes aside from remote branch. You can save your current work state, switch to different version and restore it later.

In order to quickly inspect list of local stashes content in your working copy you can use the following command:

git stash list | awk -F: '{ print "\n\n\n\n"; print $0; print "\n\n"; system("git –no-pager stash show -p " $1); }' | less

If  you see a change should be deleted it's pretty easy:

git stash drop "stash@{2}"

To load any change onto working copy:

git stash pop "stash@{2}"

Pretty simple, but powerful tool.

04/01/2012

GIT hooks: commit-msg to enforce commit rules

Filed under: en — Tags: , , — dariusz.cieslak @

Recently I forgot to add #reviewthis directive for modifications of codebase that belongs to team A. And a subtle bug was introduced that way. Ops! I agreed earlier that all changes done to moduleB should be passed to a reviewer that will do peer review for that particular change. What a shame :-( (We are using excellent GitHub's  review mechanism, BTW).

How to avoid that situation in a future? Should I rely on my memory? Is it possible for a human to track so many small rules manually? My intuition tells me that enforcement of those small ruleset should be automated.

GIT allows you to specify so called "commit hooks" that can validate many stages of GIT workflow. I'll use simplest local verification of commit message, first the rule in plain text:

If you are changing moduleB you should notify developerC about this change

(more…)

17/10/2011

Bazaar to GIT migration

Filed under: en — Tags: , , , — dariusz.cieslak @

Today I've moved using site-uptime.net development from Bazaar repository to GIT using elegant bzr2git script. The why:

  • In-place branches (I used to use them heavily)
  • Faster (no Python libs loading during "cold" start)
  • Can't live without "git rebase -i" now :-)

15/09/2011

Fixing invalid comment / branch name in GIT

Filed under: en — Tags: , — dariusz.cieslak @

Recently I was asked to help with fixing branch that had:

  • invalid name (wrong artifact number)
  • invalid comment inside (also based on wrong artifact number)

it was a mistake and programmer wanted to preserve changes done on branch, but using different name.

The solution I proposed was to:

(more…)

Older Posts »

Powered by WordPress