📝 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/hooks/index.rst

@@ -25,8 +25,8 @@ in a Git repository, including:
 |               | `push-to-checkout`_                                   |
 +---------------+-------------------------------------------------------+
 
-They can be located either in local or server-side repositories. This allows Git
-repositories to be customised and user-defined actions to be triggered.
+They can be located in either local or server-side repositories, allowing you to
+customise Git repositories and trigger user-defined actions.
 
 Git hooks are located in the :file:`.git/hooks/` directory. When a repository is
 created, some sample scripts are already created there:
@@ -57,11 +57,35 @@ The integrated scripts are shell and Perl scripts, but any scripting language
 can be used. The Shebang line (:samp:`#!/bin/sh`) determines how the file is to
 be interpreted.
 
-However, the scripts cannot be copied into the server-side repository.
+However, the scripts are not copied to the Git server using `git push`. To be
+able to use scripts across multiple repositories, the :doc:`pre-commit` is
+therefore recommended.
 
 .. seealso::
    * `Hooks <https://git-scm.com/docs/githooks#_hooks>`_
 
+Configuration-based hooks
+-------------------------
+
+.. version-added:: 2.54
+
+   Git 2.54 now introduces a new way to define hooks in your configuration
+   files: instead of placing a script in :file:`.git/hooks/pre-commit`, you can
+   now specify the following:
+
+   .. code-block:: ini
+
+      [hook "ruff check"]
+         event = pre-commit
+         command = ~/bin/ruff check --fix --exit-non-zero-on-fix
+
+   However, this configuration can be specified not only for each project, but
+   also globally or system-wide in :file:`~/.gitconfig` or in
+   :file:`/etc/gitconfig`.
+
+   Use ``git hook list pre-commit`` to find out which hooks are configured and
+   where they come from.
+
 .. toctree::
     :hidden:
 

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

@@ -162,3 +162,7 @@ Miscellaneous
 
 .. 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,16 @@
-Change commits for a clean log
-==============================
+Rewriting history
+=================
 
-With ``git commit --fixup`` and ``git rebase --autosquash`` you can correct a
-series of commits relatively easily. To demonstrate this with an example, I
-present the following scenario:
+There are several commands in Git for rewriting history. ``git rebase -i`` is
+the best known and most flexible: you can reorder, merge, edit and remove
+commits. However, this flexibility comes with a degree of complexity: your
+`working tree <https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-workingtree>`_ and `index <https://git-scm.com/docs/gitglossary#def_index>`_
+are updated, and conflicts may arise that need to be resolved before you can
+continue working.
+
+With ``git commit --fixup`` and ``git rebase --autosquash``, on the other hand,
+you can correct a series of commits relatively easily. Let’s demonstrate this
+with an example below:
 
 #. We have two commits in our ``my-feature`` branch: one for the actual
    function, the other for the associated tests:
@@ -64,8 +71,8 @@ present the following scenario:
       132ae9b Add new feature
 
 #. The changes can now be pushed to our remote branch using ``git push
-   --force-with-lease``. ``--force-with-lease`` option ensures that any existing
-   changes on the remote branch are not overwritten.
+   --force-with-lease``. The ``--force-with-lease`` option ensures that any
+   existing changes on the remote branch are not overwritten.
 
 …with ``git commit --fixup`` and ``git rebase --autosquash``
 ------------------------------------------------------------
@@ -118,3 +125,29 @@ In Git, however, there is an even easier way to correct a previous commit: with
 
       Further options can be found in the `Git commit documentation
       <https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---fixupamendrewordltcommitgt>`_.
+
+``git history``
+---------------
+
+.. version-added:: 2.54
+
+   Git 2.54 introduces ``git history`` on an experimental basis, meaning that
+   the interface is still subject to further development. ``git history`` makes
+   it easier to correct typos in previous commit messages and to split commits
+   into two parts:
+
+   :samp:`git history reword {SHA}`
+       opens your editor with the message of the specified commit and rewrites
+       it directly, updating all branches descended from that commit. Unlike
+       :doc:`../rebase`, it does not access your working tree or your index.
+   :samp:`git history split {SHA}`
+       interactively splits a commit into two parts, allowing you to select
+       which parts should be moved into a new parent commit. The interface is
+       the same as that of ``git add --p``. After selecting the blocks, Git
+       creates a new commit with these changes as a predecessor to the original
+       commit, which retains all unselected blocks, and rewrites all downstream
+       branches so that they point to the updated history.
+
+   .. warning::
+      ``history`` does not support histories containing merge commits, nor can
+      it perform operations that would result in a merge conflict.