📝 Update git section

* Add git history and config-based hooks
* Add links to Sourcegraph to find pre-commit hooks

Author: veit

docs/productive/git/advanced/exceltocsv.py

@@ -3,7 +3,6 @@
 # SPDX-License-Identifier: BSD-3-Clause
 
 import sys
-
 from io import StringIO
 
 import pandas as pd

docs/productive/git/advanced/hooks/index.rst

@@ -6,7 +6,7 @@ Git Hooks
 =========
 
 Git-Hooks sind Skripte, die bei bestimmten Ereignissen in einem Git-Repository
-automatisch ausgeführt werden, :abbr:`u.a. (unter anderem)`:
+automatisch ausgeführt werden, :abbr:`u. a. (unter anderem)`:
 
 +---------------+-------------------------------------------------------+
 | Befehl        | Hooks                                                 |
@@ -25,9 +25,9 @@ automatisch ausgeführt werden, :abbr:`u.a. (unter anderem)`:
 |               | `push-to-checkout`_                                   |
 +---------------+-------------------------------------------------------+
 
-Sie können sich entweder in lokalen oder serverseitigen Repositories befinden.
-So können Git-Repositories individuell angepasst und benutzerdefinierte Aktionen
-ausgelöst werden.
+Sie können sich entweder in lokalen oder serverseitigen Repositories befinden
+und erlauben so, Git-Repositories individuell anzupassen und benutzerdefinierte
+Aktionen auszulösen.
 
 Git Hooks befinden sich im Verzeichnis :file:`.git/hooks/`. Beim Anlegen eines
 Repository werden dort auch bereits einige Beispielskripte angelegt:
@@ -59,11 +59,35 @@ Die integrierten Skripte sind Shell- und Perl-Skripte, es können jedoch
 beliebige Skriptsprachen verwenden werden. Dabei bestimmt die Shebang-Zeile
 (:samp:`#!/bin/sh`), wie die Datei interpretiert werden soll.
 
-Die Skripte können jedoch nicht in das serverseitige Repository kopiert werden.
+Die Skripte werden jedoch mit ``git push`` **nicht** auf den Git-Server kopiert.
+Um Skripte in mehreren Repositories verwenden zu können, empfiehlt sich daher
+das :doc:`pre-commit`.
 
 .. seealso::
    * `Hooks <https://git-scm.com/docs/githooks#_hooks>`_
 
+Konfigurationsbasierte Hooks
+----------------------------
+
+.. version-added:: 2.54
+
+   Git 2.54 führt nun eine neue Möglichkeit ein, Hooks in euren
+   Konfigurationsdateien zu definieren: Anstatt eines Skripts in
+   :file:`.git/hooks/pre-commit` abzulegen, kann nun folgendes angegeben werden:
+
+   .. code-block:: ini
+
+      [hook "ruff check"]
+         event = pre-commit
+         command = ~/bin/ruff check --fix --exit-non-zero-on-fix
+
+   Diese Konfiguration kann jedoch nicht nur für jedes Projekt angegeben werden,
+   sondern auch global oder systemweit in :file:`~/.gitconfig` oder in
+   :file:`/etc/gitconfig`.
+
+   Mit ``git hook list pre-commit`` erfahrt ihr, welche Hooks konfiguriert sind
+   und woher sie stammen.
+
 .. toctree::
     :hidden:
 

docs/productive/git/advanced/hooks/scripts.rst

@@ -173,3 +173,7 @@ Misc
 
 .. seealso::
     * `Supported hooks <https://pre-commit.com/hooks.html>`_
+    * `Sourcegraph: file:^\.pre-commit-config\.yaml$
+      <https://sourcegraph.com/search?q=context:global+file:%5E.pre-commit-hooks.yaml>`_
+    * `Sourcegraph: file:^\.pre-commit-hooks\.yaml$ \"types: [python]\"
+      <https://sourcegraph.com/search?q=context:global+file:%5E.pre-commit-hooks.yaml%24+%22types:+%5Bpython%5D%22>`_

docs/productive/git/workflows/clean-history.rst

@@ -1,9 +1,18 @@
-Commits für ein sauberes Log ändern
-===================================
-
-Mit ``git commit --fixup`` und ``git rebase --autosquash`` könnt ihr relativ
-einfach eine Reihe von Commits korrigieren. Um dies an einem Beispiel zu
-demonstrieren, stelle ich euch folgendes Szenario vor:
+Geschichte umschreiben
+======================
+
+Es gibt in Git mehrere Befehle zum Umschreiben der Geschcihte. ``git rebase -i``
+ist das bekannteste und flexibelste: ihr könnt Commits neu anordnen,
+zusammenfassen, bearbeiten und entfernen. diese Flexibilität geht jedoch mit
+einiger Komplexität einher: euer `Working Tree
+<https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-workingtree>`_
+und euer `Index <https://git-scm.com/docs/gitglossary#def_index>`_ werden
+aktualisiert und Konflikte können entstehen, die gelöst werden müssen, bevor ihr
+mit der Arbeit fortfahren könnt.
+
+Mit ``git commit --fixup`` und ``git rebase --autosquash`` könnt ihr hingegen
+relativ einfach eine Reihe von Commits korrigieren. Im Folgenden wollen wir dies
+an einem Beispiel demonstrieren:
 
 #. Wir haben in unserem ``my-feature``-Branch zwei Commits: den einen für die
    eigentliche Funktion, den anderen für die zugehörigen Tests:
@@ -64,8 +73,10 @@ demonstrieren, stelle ich euch folgendes Szenario vor:
       31a140a (my-feature) Add test for my new feature
       132ae9b Add new feature
 
-#. Die Änderungen können nun mit ``git push -f`` an unseren entfernten Zweig
-   gesendet werden.
+#. Die Änderungen können nun mit ``git push --force-with-lease`` an unseren
+   entfernten Zweig gesendet werden. ``--force-with-lease`` gewährleistet, dass
+   Änderungen im entfernten Zweig :abbr:`ggf. (gegebenenfalls)` nicht
+   überschrieben werden.
 
 …mit ``git commit --fixup``  und ``git rebase --autosquash``
 ------------------------------------------------------------
@@ -118,3 +129,32 @@ korrigieren: mit ``git commit--fixup`` und ``git rebase --autosquash``.
 
       Weitere Optionen findet ihr in der `Git Commit-Dokumentation
       <https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupamendrewordltcommitgt>`_.
+
+``git history``
+---------------
+
+.. version-added:: 2.54
+
+   Git 2.54 führt experimentell ``git history`` ein, :abbr:`d. h. (das heißt)`,
+   dass sich die Schnittstelle noch weiterentwickeln kann. Mit ``git history``
+   wird die Korrektur von Tippfehlern früherer Commit-Meldungen und das
+   Aufteilen von Commits in zwei Teile erleichtert:
+
+   :samp:`git history reword {SHA}`
+       öffnet deinen Editor mit der Nachricht des angegebenen Commits und
+       schreibt diese direkt um, wobei alle Zweige aktualisiert werden, die von
+       diesem Commit abstammen. Im Gegensatz zu :doc:`../rebase` greift es weder
+       auf deinen Working Tree noch auf deinen Index zu.
+   :samp:`git history split {SHA}`
+       teilt einen Commit interaktiv in zwei Teile, wobei ihr auswählt, welche
+       Teile in einen neuen übergeordneten Commit ausgelagert werden sollen. Das
+       Interface entspricht dem von ``git add –p``. Nach der Auswahl der Blöcke
+       erstellt Git einen neuen Commit mit diesen Änderungen als Vorgänger des
+       ursprünglichen Commits, der alle nicht ausgewählten Blöcke beibehält, und
+       schreibt alle nachgelagerten Zweige um, sodass sie auf den aktualisierten
+       Verlauf verweisen.
+
+   .. warning::
+      ``history`` unterstützt keine Historien, die Merge-Commits enthalten, und
+      es können auch keine Operationen ausgeführt werden, die zu einem
+      Merge-Konflikt führen würden.