Tag Archives: git

Stuff I’ve learned #04

Time has passed…

  • In commit messages, describe intent rather than implementation details. (thanks Remco!)
  • Using github? Then you can refer to issues in your commit messages using #. Ie when there is an issue (#12), and you want to fix it. Just refer to it with a #12 and Github will automatically link your commit to the issue.
  • It always takes more time then you always think to revamp your project(s).
  • Start with why. Easier said then done though. (Reading the book, so I might write a review about that soon)
  • Paypal’s functionality to change your password sucks. Perhaps I’d write a blog about it…
  • Github already rocks by making it so easy to host repo’s, and with Travis’ integration it made me drool. Especially when I wanted to merge a pull request:
    Screen Shot 2013-09-11 at 3.18.31 PM Screen Shot 2013-09-11 at 3.27.44 PM

Stuff I’ve learned #03

Another week has passed:

  • Unlike in Windows; in Chrome you cannot easily focus on your bookmarks bar with a keyboard short key on Mac OS X.
  • If you want to run rake tasks in your specs in a before block, be sure to set a line[code language=”ruby”]Rake::Task[name].reenable[/code]

    so you can re-execute them every time. Rake seems to remember which task has been executed, so you cannot execute it twice.

  • If you want to stub out STDOUT messages (like with ‘puts’) in your spec, use:[code language=”ruby”]STDOUT.stubs(:puts)[/code]
  • When in doubt, speak up. Always.
  • With Scrum, big stories are big risks. Split them up.
  • Don’t use PID files to remember which proces has been started and when it should be stopped. Especially if you want to reboot a deamon process automatically once it has died. Instead wait for it when the deamon has quit and act upon a not-normal exit code.
  • Sometimes using ‘git fetch -p’ is not enough to prune all your local branches (which do not exist anymore on remote). You can use a rather long command (see below, from stackoverflow question)[code language=”shell”]git branch -r | awk ‘{print $1}’ | egrep -v -f /dev/fd/0 <(git branch -vv | grep origin) | awk ‘{print $1}’ | xargs git branch -d[/code]
  • With editorconfig (*) you can create code formatting rules, nothing new here, but editorconfig has plugins for a lot of known editors, (I tested it in Vim & Sublime), meaning you can now share these rules cross-editor. Now that is cool!
  • With C++, when your function argument is using const, and you’re calling a non-const function on that argument you will end up with a message like:

    “error: passing ‘const xxx’ as ‘xxx’ argument of ‘function you where trying to call on xxx’ discards qualifiers”.

    You can fix this by telling the function body is const:

    [code language=”cpp”] bool myFunction() const { /* code here */ } [/code]

* Thx to Arjen about editorconfig.

Worst Commit – Ever

Got this via a friend and had to share this with you…

Ever heard of Bumblebee? Well I thought it was about this guy:

Apparently it wasn’t, in this case.

In fact, I still don’t even know what piece of software it is, but I do know about one of its most famous commits on github now.

This commit is very small, yet makes a very big difference for the user…

If you want to have a laugh see the commit yourself, and then all the comments, they are hilarous.

Ok, one teaser:

Still reading…?

Terminal: Show git branch, changes, RVM ruby version, gemset.

I was looking for a way to easily print the current gemset I am in when working in the terminal. I found a stack overflow post, but it did not really satisfy me. With some googling I also found this post.

I modified the script a tiny bit (color preferences + added __git_ps1 to detect branch) and would like to share you what I’ve got.

This is the complete script I use now, copy & paste if you like.

The result looks like this:

terminal

[sourcecode]
# This shows the git branch of the current directory
function __git_ps1 () {
git branch 2> /dev/null | sed -e ‘/^[^*]/d’ -e ‘s/* (.*)/ (1)/’
}

function __git_dirty {
git diff –quiet HEAD &>/dev/null
[ $? == 1 ] && echo " (changes!)"
}

function __git_branch {
__git_ps1 " %s"
}

function __my_rvm_ruby_version {
local gemset=$(echo $GEM_HOME | awk -F’@’ ‘{print $2}’)
[ "$gemset" != "" ] && gemset="@$gemset"
local version=$(echo $MY_RUBY_HOME | awk -F’-‘ ‘{print $2}’)
[ "$version" == "1.8.7" ] && version=""
local full="$version$gemset"
[ "$full" != "" ] && echo "$full "
}

bash_prompt() {
local NONE="[\033[0m]"    # unsets color to term’s fg color

# regular colors
local K="[\033[0;30m]"    # black
local R="[\033[0;31m]"    # red
local G="[\033[0;32m]"    # green
local Y="[\033[0;33m]"    # yellow
local B="[\033[0;34m]"    # blue
local M="[\033[0;35m]"    # magenta
local C="[\033[0;36m]"    # cyan
local W="[\033[0;37m]"    # white

# emphasized (bolded) colors
local EMK="[\033[1;30m]"
local EMR="[\033[1;31m]"
local EMG="[\033[1;32m]"
local EMY="[\033[1;33m]"
local EMB="[\033[1;34m]"
local EMM="[\033[1;35m]"
local EMC="[\033[1;36m]"
local EMW="[\033[1;37m]"

# background colors
local BGK="[\033[40m]"
local BGR="[\033[41m]"
local BGG="[\033[42m]"
local BGY="[\033[43m]"
local BGB="[\033[44m]"
local BGM="[\033[45m]"
local BGC="[\033[46m]"
local BGW="[\033[47m]"

local UC=$W                 # user’s color
[ $UID -eq "0" ] && UC=$R   # root’s color

PS1="$M$(__my_rvm_ruby_version)$Wh$W:$EMGw$EMC$(__git_branch)$EMW$(__git_dirty)${NONE} $ "
}

bash_prompt
unset bash_prompt
[/sourcecode]

Applying a GIT patch on your local SVN repository

Recently someone is helping me out on my Dune II – The Maker project. He works with GIT, a version control system like SVN. I don’t care about the differences between them at this point, except for one difference: The patch files.

So here is the situation: Someone works with GIT, makes some changes and creates a patch file out of them. He sends it to me so I can apply it to my SVN repository. In theory, I thought, this would work fine. Atleast I think the possibility to share patches among different versioning systems would be great, but there is a problem.

The GIT patch file format is different compared to a ‘normal unified diff’ patch, and therefor my SVN client (I use TortoiseSVN) does not understand the patch file and will not apply it. Side note: It does not mention it doesn’t understand it, it simply does nothing.

I found a sollution for this that works 90% of the time (for me). There is TortoiseGIT , which basically offers the same windows integration as TortoiseSVN. However, looking into the ToirtoiseGIT install dir (within the BIN sub-dir) you can find TortoiseMerge.

TortoiseMerge is used within TortoiseSVN for merging and applying (unified diff) patches. But the TortoiseMerge tool within TortoiseGIT understands GIT patch files.

So here is the blunt solution: Open up TortoiseMerge from TortoiseGIT. Open the GIT patch file with it and apply it on your checked-out SVN repository. TortoiseMerge will apply the patch 9 out of 10 times for you.

Sometimes you might encounter an error that TortoiseMerge cannot apply the patch due ‘missing lines’. In those cases I found myself reading the patch file itself and apply it by hand.

I hope this helped you out, if it did (or not) let me know.