Ein Blog

Posts mit Tag "git"

Eine einfache Web-ReadOnly-Oberfläche für Git-Repos: Klaus

Ich habe gerade folgenden Alias bei Git hinzugefügt:

git config --global alias.serve "daemon --verbose --export-all --base-path=.git --reuseaddr --strict-paths .git/"

Damit kann man ein lokales Git-Repo “mal schnell” serven, damit es jemand klonen kann. Dann spart man sich SSH bzw. andere Lösungen (Quelle).

git-trim automatically trims your tracking branches whose upstream branches are merged or stray.

Ein Command-Explorer für Git, der ein tl;dr zu allen Commands gibt.

Bei Git kann man demnächst auch mit dem SSH-Schlüssel signieren.

Highlights from Git 2.34.

Highlights from Git 2.35.

Ein super Talk über häufig nicht verwendete Sachen in git: So You Think You Know Git? von Scott Chacon, einem Mitgründer von GitHub und dem CEO vom Git-Client GitButler.

GitHub stellt bei einem Repo alle PRs als Ref bereit. So braucht man bei einem PR eines externen Repos nicht ein anderes Repo als Remote hinzufügen, sondern kann es direkt fetchen und auschecken. Der Name ist pull/$ID/head.

Hier ein Alias für git:

git config --global alias.pr '!f() { git fetch origin pull/$1/head:pr/$1 && git switch pr/$1; }; f'

Hatten es gerade im Team, ging um Formatierungs-Commits.

Da gibt es ja 2 Ansätze, die man gehen kann:

  1. Einen pre-commit-hook, der die Dateien formatiert, die ein Commit sowieso anpasst.
  2. Einzelne Formatierungs-Commits, die mehrere Dateien anfassen

Bei 1. is der Vorteil, dass man wenige bis gar keine Konflikte bekommt, wenn andere noch in anderne Branches arbeiten. Der Nachteil ist, dass man Änderungen in einem Commit hat, die nicht zu der Fachlichkeit gehören, die man in dem Commit gerade tätigt. Beides ist mehr oder weniger gut/schlimm.

Der 2. Ansatz ist genau umgekehrt: Er hat keine Vermischung mit fachlichen Änderungen, aber ein hohes Potential für Konflikte.

Beide haben aber ein Problem: Sie machen ggf. git blame für die formatierten Zeilen kaputt. Zumindest für Ansatz 2 gibt es da einen Fix: .git-blame-ignore-revs. Die Datei beinhaltet Commit-Hashes von Commits, die bei git blame ignroriert werden sollen. So sind reine “Format”-Commits nicht mehr so schlimm.

GitHub respektiert die Datei auch bei der Blame-View, solange sie diesen Namen hat. Damit das lokale Git das auch respektiert, muss man es konfigurieren:

# repo
git config blame.ignoreRevsFile .git-blame-ignore-revs
# global
git config --global blame.ignoreRevsFile .git-blame-ignore-revs

Alternativ kann man auch einen Dateinamen bei Blame übergeben:

git blame --ignore-revs-file .git-blame-ignore-revs foo.py

Oder einen einzelnen Commit ignorieren:

git blame --ignore-rev d34db33f

Hier ist noch ein Blogpost dazu.

Git Notes: git’s coolest, most unloved­ feature. Hier noch die Doku dazu.

Man kann bei Git ja mit includeIf gut verschiedene Configs basierend auf dem Repo-Verzeichnis einbinden. So kann man z.b. erreichen, dass immer die richtige Committer-Email oder der richtige PGP-Key zum signieren verwendet wird.

Was ich heute gelernt habe: Man kann das auch auf Remotes matchen:

[includeIf "hasconfig:remote.*.url:git@gitlab.com:*/**"]
  path = ~/.config/git/config-gl

How Core Git Developers Configure Git.

Tracking SQLite Database Changes in Git. Hier gibt es noch einen weiteren Trick, der nicht die SQLite-DB als Blob speichert, sondern als Plain-Text.

Gaining advanced insights from Git repository history.

Das Git-Projekt arbeitet an einer built-in-Lösung für große Dateien als Alternative zu Git LFS.