Manchmal sitzt man so vor einem Terminal, hat fröhlich-chaotisch vor sich hin gehackt, natürlich alles brav auf einem eigenen chaotisch-vor-sich-hin-hack-Branch, und fühlt, dass die Zeit reif ist, die Früchte seiner Arbeit in den master-Branch zurückfließen zu lassen. Nur: Was sind denn die Früchte besagter Arbeit?
Im grafischen Display von Gitk ist das schnell erkannt: Gitk öffnen, die Commits ansehen, die man auf dem Branch eingebracht hat, und schon kann man entscheiden, ob man wirklich auf den master mergen will oder nicht. Nur was ist, wenn's auf dem Terminal keine grafische Darstellung gibt?
Kein Problem. Gitk ist ja im Grunde nur ein glorifiziertes git log (wenn auch recht gut glorifiziert), also kann man alles, was man mit gitk machen kann, auf mit git log machen, ganz ohne grafische Ausgabe.
In diesem Falle interessieren uns alle Commits auf dem Branch hacking, der von master abgezweigt. Das bedeutet, dass alle Commits, die auf hacking liegen, angezeigt werden sollen, aber keine Commit, die auf master liegen. Und so geht's:
git log hacking ^master
Eigentlich ganz einfach. Natürlich gibt's noch jede Menge Optionen für git log, mit dem man anpassen kann, was genau wie ausgegeben wird. Beliebt sind in diesem Zusammenhang --oneline und --graph. Aber wenn man wirklich will geht da noch viel mehr...
Dienstag, 19. Februar 2013
Dienstag, 12. Februar 2013
Git Status in der Bash, Teil 2
Vor ein paar Jahren hatte habe ich unter Git Status in der Bash meine PS1-Definition abgetippert. Das war eine Kombination aus Bash-Funktionen und einem Prompt-String, die auch lange Zeit ganz gut funktioniert hat. Mit einem der aktuellen Git-Updates (aus der 1.8x-Reihe, wenn ich mich nicht irre) ist das dann umgefallen: Weil Git eine Ausgabezeile geringfügig geändert hat, zeigte das Skript grundsätzlich alle Working Directories als "modified" an. Ärgerlich.
Aber ein Grund, etwas zu verbessern. Die Skripte, die den Status des aktuellen Working Directory anzeigen, gibt's nämlich im Rahmen der normalen Git-Installation unter contrib. (Wer das in seinem Ubuntu nicht findet: In den Git-Sourcen ist das vollständige contrib-Verzeichnis enthalten, einfach einmal clonen und dann contrib/completion/git-prompt.sh einbinden).
Jetzt kommen die folgenden Zeilen in die .profile/.bashrc:
./contrib/completion/git-prompt.sh
PS1='\[\e]0;\w $(__git_ps1 " %s")\a\]\n\[\e[32m\]\u@\h \
\[\e[33m\]\w $(__git_ps1 " %s")\[\e[0m\]\n\$ '
Noch ein wenig an den eigenen Geschmack anpassen, und schon ist es fertig. Wer es ein wenig hübscher will, findet in git-prompt.sh noch Hinweise, was man noch so alles tweaken kann.
Das Beste zum Schluss: Da das contrib-Verzeichnis von den Git-Contributors gepflegt wird, bekommt man immer funktionierende für die gerade verwendete Git-Version.
Aber ein Grund, etwas zu verbessern. Die Skripte, die den Status des aktuellen Working Directory anzeigen, gibt's nämlich im Rahmen der normalen Git-Installation unter contrib. (Wer das in seinem Ubuntu nicht findet: In den Git-Sourcen ist das vollständige contrib-Verzeichnis enthalten, einfach einmal clonen und dann contrib/completion/git-prompt.sh einbinden).
Jetzt kommen die folgenden Zeilen in die .profile/.bashrc:
.
PS1='\[\e]0;\w $(__git_ps1 " %s")\a\]\n\[\e[32m\]\u@\h \
\[\e[33m\]\w $(__git_ps1 " %s")\[\e[0m\]\n\$ '
Noch ein wenig an den eigenen Geschmack anpassen, und schon ist es fertig. Wer es ein wenig hübscher will, findet in git-prompt.sh noch Hinweise, was man noch so alles tweaken kann.
Das Beste zum Schluss: Da das contrib-Verzeichnis von den Git-Contributors gepflegt wird, bekommt man immer funktionierende für die gerade verwendete Git-Version.
Abonnieren
Kommentare (Atom)