Auch wenn ich nicht wirklich ‚viel‘ code, aber so ab und zu fällt ja doch mal was an … In den letzten Jahren v.a. aber eher Klein(st)beiträge zu bereits bestehndem Code Anderer, statt eigener Projekte.

2010 versuchte ich meine ersten Schritt(ch)e(n) mit Git und suchte dafür eine geeignete Plattform. – Nur Kommandozeile mit eigenem Git-Server war mir damals IMHO zu umständlich und wohl auch zu nerdy. ‚Damals‘ gabs zwar schon Github (und dort hatte ich auch seit 2009 einen ungenutzten Account), aber als F(L)OSS-Verfächter wollte ich mehr Community und fand letztlich Gitorious, wo ich mir einen Account zulegte. (So jedenfalls meine Erinnerung …)

Bei Gitorious gab es anfänglich keinen Issue-Tracker und die Interaktion über Weboberfläche war, im Gegensatz zu Github, sehr beschränkt. So kam es im Laufe der folgenden fünf Jahre zur vorrangigen Nutzung meines Github-Accounts.

Im letzten Jahr gab es Bedarf für die Zusammenarbeit mehrer Personen ein einem Projekt (etwas bug fixing im Code von POLYKON) – dabei sollte das erst einmal nicht in der Öffentlichkeit passieren. Somit schied Github (auf Grund der Kosten) aus und ich fand BitBucket und erstellte auch dort einen Account.

In Summe hatte ich bis dahin also drei Accounts bei unterschiedlichen Anbietern für Git-Repositories gesammelt …

Letzte Woche wollte ich mal wieder bei Gitorious schauen, was so los ist und stellte fest, dass GitLab den Laden übernommen hat und man empfiehlt, die eigenen Gitorious-Repos auf GitLab umzuziehen. Dann habe ich mich also mal bei GitLab umgeschaut und schwupps, war der vierte Account geklickt … 😉

Warum nun noch einen vierten Account?

  • GitLabs Webinterface ist schnell
  • GitLab bietet nichtöffentliche Repos an
  • GitLab bietet eig. alle (von mir benutzten) Features wie Github (und ist sogar besser ;))
  • GitLab gibts in der Community Version kostenlos
  • und jetzt der Knaller: per Klick konnte ich (mit etwas Recherche) alle Repos aus den anderen drei Accounts importieren
  • wenn die Butze iwann (vllt.) mal zu macht, dann kann ich/man das immer noch selber hosten
  • das Icon ist süüüß … 😉

Zusammengefasst: Aktuell schrumpfe/konsolidiere ich meine Git-Plattform-Accounts. Gitoriuous is schon weg und gleich kommt noch der Bitbucket-Account dran. Bei Github werde ich dann wohl nur noch wg. der Issue- und Pull-Request-Zwecke sein, die eigenen Projekte kommen dort auf jeden Fall weg.

Mal schauen, ob sich das Aufräumen langfristig als klug erweisen wird …

Old but not busted … – Dieser Inhalt wurde vor mehr als 6 Jahren publiziert. Die Korrektheit und Verfügbarkeit von Links können leider nicht gewährleistet werden.

The followig post is not written by myself. It’s a copy! – Today I found the article in the Google Cache and thought there are more people (than me) interested in the archived text that was originally published at a blog named M-x Kelsin.
Let’s start:

After reading another cool blog post about putting your current git branch in your bash prompt I decided I needed to try this out. Once I got it working I added in color coding to see the status of the current checkout as well!

First off, you need bash-completion and git installed on your server (bash-completion and git-core on Debian/Ubuntu). Once installed you can enable bash completion in the system wide bash file (/etc/bash.bashrc) or in your own ~/.bashrc by adding these lines (Clearly if you are not on Debian/Ubuntu double check file paths):

# Completion
if [ -f /etc/bash_completion ]; then
    . /etc/bash_completion
fi

Once this is all set you should have a function called git_ps1 available. Try it out by just running „git_ps1″ on your command line from a git repo. You should get the branch name returned inside parenthesis’s.

Now comes my variations on how to include this in your prompt. My entire ~/.bash_prompt file can be found on my git repo. I source this file into my ~/.bashrc. The two most interesting parts are the function that determines the color of the branch based on git-status output and the function that gets the branch name. Branch name is pretty simple. We check that the __git_ps1 function is available and if it is, check that we‘re in a branch using it. If we are we echo the branch name. Pretty clean.

prompt_git_branch() {
    if type -p __git_ps1; then
        branch=$(__git_ps1 '%s')
        if [ -n "$branch" ]; then
            echo -e "$branch"
        fi
    fi
}

The next function has to grep stuff out of git status to determine what state the repo is in. If we are completely up to date we use green. If I have local changes it’s blue. If we have files in our index ready to be committed I use red. This is really great with my home directory cause it helps remind me to add new dotfiles that I don’t care about to .gitignore (or commit them if they should be public config files).

prompt_git_branch_color() {
    if type -p __git_ps1; then
        branch=$(__git_ps1 '%s')
        if [ -n "$branch" ]; then
            status=$(git status 2> /dev/null)

            if $(echo $status | grep 'added to commit' &> /dev/null); then
                # If we have modified files but no index (blue)
                echo -e "\033[1;34m"
            else
                if $(echo $status | grep 'to be committed' &> /dev/null); then
                    # If we have files in index (red)
                    echo -e "\033[1;31m"
                else
                    # If we are completely clean (green)
                    echo -e "\033[1;32m"
                fi
            fi
        fi
    fi
}

It took some playing but I finally found the right final line to correctly tell bash which characters in the prompt are visible. If anyone has a good way of making these functions smaller or faster I‘d love to hear it. I had some trouble making sure that the functions were always executed (not just on a new shell’s creation, but on every display of PS1). The speed is FINE on all of my computers but more speed never hurts.