Wie kann ich in Git den aktuellen Commit-Hash in eine Datei im selben Commit schreiben?

Ich versuche hier ein ausgefallenes Zeug mit Git-Hooks zu machen, aber ich weiß nicht wirklich, wie ich es machen soll (oder ob es möglich ist).

Was ich tun muss, ist: In jedem Commit möchte ich seinen Hash nehmen und dann eine Datei im Commit mit diesem Hash aktualisieren.

Irgendwelche Ideen?

Ich würde empfehlen, etwas Ähnliches zu tun, wie Sie es sich vorgestellt haben: Platzieren des SHA1 in einer nicht verfolgten Datei, die im Rahmen des Erstellungs- / Installations- / Bereitstellungsprozesses generiert wird. Es ist offensichtlich einfach zu tun (git rev-parse HEAD > filename oder vielleicht git describe [--tags] > filename) und es vermeidet es, etwas Verrücktes zu tun, wie eine Datei zu erhalten, die sich von der Verfolgung durch Git unterscheidet.

Ihr Code kann dann auf diese Datei verweisen, wenn er die Versionsnummer benötigt, oder ein Erstellungsprozess kann die Informationen in das Endprodukt integrieren. Letzteres ist tatsächlich, wie Git selbst seine Versionsnummern erhält - der Erstellungsprozess holt die Versionsnummer aus dem Repo und baut sie dann in die ausführbare Datei ein.

Es ist unmöglich, den aktuellen Commit-Hash zu schreiben: Wenn Sie den zukünftigen Commit-Hash vorberechnen können, ändert sich dieser, sobald Sie eine Datei ändern.

Es gibt jedoch drei Möglichkeiten:

1. Verwenden Sie ein Skript, um die Festschreibungs-ID zu erhöhen und irgendwo einzufügen. Hässlich
2. .gitignore die Datei, in der Sie den Hash speichern möchten. Nicht sehr praktisch
3. In pre-commitspeichern die vorherigen Hash begehen :) Sie nicht ändern / Insert - Commits in 99,99% der Fälle, so, dies funktionieren wird. Im schlimmsten Fall können Sie die Quellrevision immer noch identifizieren.

Ich arbeite an einem Hook-Skript, werde es hier veröffentlichen, wenn es fertig ist, aber immer noch - früher als Duke Nukem Forever veröffentlicht wird :))

Update : Code für .git/hooks/pre-commit:

#!/usr/bin/env bash
set -e

#=== 'prev-commit' solution by o_O Tync
#commit_hash=$(git rev-parse --verify HEAD)
commit=$(git log -1 --pretty="%H%n%ci") # hash \n date
commit_hash=$(echo "$commit" | head -1)
commit_date=$(echo "$commit" | head -2 | tail -1) # 2010-12-28 05:16:23 +0300

branch_name=$(git symbolic-ref -q HEAD) # http://stackoverflow.com/questions/1593051/#1593487
branch_name=${branch_name##refs/heads/}
branch_name=${branch_name:-HEAD} # 'HEAD' indicates detached HEAD situation

# Write it
echo -e "prev_commit='$commit_hash'\ndate='$commit_date'\nbranch='$branch'\n" > gitcommit.py

Jetzt brauchen wir nur noch ein Tool, das prev_commit,branchPaare in einen echten Commit-Hash konvertiert :)

Ich weiß nicht, ob dieser Ansatz das Zusammenführen von Commits voneinander unterscheiden kann. Werde es bald überprüfen

Jemand hat mich auf den Abschnitt "man gitattributes" auf ident hingewiesen, der Folgendes enthält:

ident

Wenn das Attribut ident für einen Pfad festgelegt ist, ersetzt git $ Id $ im Blob-Objekt durch $ Id:, gefolgt vom 40-stelligen hexadezimalen Blob-Objektnamen, gefolgt von einem Dollarzeichen $ beim Auschecken. Jede Byte-Sequenz, die mit $ Id: beginnt und in der Arbeitsbaumdatei mit $ endet, wird beim Einchecken durch $ Id $ ersetzt.

Wenn Sie darüber nachdenken, ist dies auch das, was CVS, Subversion usw. tun. Wenn Sie sich das Repository ansehen, werden Sie feststellen, dass die Datei im Repository immer beispielsweise $ Id $ enthält. Es enthält nie die Erweiterung davon. Nur beim Auschecken wird der Text erweitert.

Dies kann erreicht werden, indem das filterAttribut in gitattributes verwendet wird . Sie müssten einen smudgeBefehl angeben, der die Festschreibungs-ID einfügt, und aclean Befehl, der sie entfernt, sodass sich die Datei, in die sie eingefügt wird, nicht nur aufgrund der Festschreibungs-ID ändert.

Daher wird die Festschreibungs-ID niemals im Blob der Datei gespeichert. Es ist nur in Ihrer Arbeitskopie erweitert. (Das Einfügen der Commit-ID in den Blob wird zu einer unendlich rekursiven Aufgabe. ☺) Jeder, der diesen Baum klont, muss die Attribute für sich selbst einrichten.

Denken Sie außerhalb des Commit-Bereichs!

Pop dies in die Datei Hooks / Post-Checkout

#!/bin/sh
git describe --all --long > config/git-commit-version.txt

Die Version ist überall verfügbar, wo Sie sie verwenden.

Ich glaube nicht, dass Sie das wirklich tun möchten, denn wenn eine Datei im Commit geändert wird, wird auch der Hash des Commits geändert.

Lassen Sie mich anhand der Git-Interna untersuchen, warum dies ein herausforderndes Problem ist. Sie können den sha1 des aktuellen Commits von abrufen

#!/bin/bash
commit=$(git cat-file commit HEAD) #
sha1=($((printf "commit %s\0" $(echo "$commit" | wc -c); echo "$commit") | sha1sum))
echo ${sha1[0]}

Im Wesentlichen führen Sie eine sha1-Prüfsumme für die von zurückgegebene Nachricht aus git cat-file commit HEAD. Zwei Dinge treten sofort als Problem auf, wenn Sie diese Nachricht untersuchen. Einer ist der Baum sha1 und der zweite ist die Festschreibungszeit.

Jetzt kann die Festschreibungszeit leicht behoben werden, indem die Nachricht geändert und erraten wird, wie lange es dauert, eine Festschreibung durchzuführen oder eine Festschreibung zu einem bestimmten Zeitpunkt zu planen. Das wahre Problem ist der Baum sha1, von dem Sie erhalten können git ls-tree $(git write-tree) | git mktree. Im Wesentlichen führen Sie eine sha1-Prüfsumme für die Nachricht von ls-tree durch, bei der es sich um eine Liste aller Dateien und ihrer sha1-Prüfsumme handelt.

Daher hängt Ihre Commit-sha1-Prüfsumme von Ihrer Baum-sha1-Prüfsumme ab, die direkt von der Datei sha1-Prüfsumme abhängt, die den Kreis schließt und von der Commit-sha1 abhängt. Sie haben also ein zirkuläres Problem mit Techniken, die mir zur Verfügung stehen.

Mit weniger sicheren Prüfsummen wurde gezeigt, dass es möglich ist, die Prüfsumme der Datei mit brutaler Gewalt in die Datei selbst zu schreiben. Ich kenne jedoch keine Arbeit, die diese Aufgabe mit sha1 erfüllt hat. Dies ist nicht unmöglich, aber nach unserem derzeitigen Verständnis nahezu unmöglich (aber wer weiß, dass es in ein paar Jahren vielleicht trivial sein wird). Dies ist jedoch noch schwieriger zu erzwingen, da Sie die (Commit-) Prüfsumme einer (Baum-) Prüfsumme einer (Blob-) Prüfsumme in die Datei schreiben müssen.