Expansion des informations Git SHA1 dans un checkin sans archivage?

Question

Existe-t-il un moyen d'inclure des hachages git commit dans un fichier chaque fois que je m'engage? Je peux seulement trouver comment faire ceci pendant l'archivage mais je n'ai pas été capable de trouver comment faire ceci pour chaque commit. Je fais de la programmation scientifique avec git comme contrôle de révision, donc ce genre de fonctionnalité serait très utile pour des raisons de reproductibilité (à savoir, avoir le git hash automatiquement inclus dans tous les fichiers de résultats et les figures).

Answer 1

Vous pouvez facilement mettre SHA-1 de fichier (pour être plus SHA-1 exacte de blob, c'est-à-dire SHA-1 du contenu du fichier) en utilisant $Id$ keywork et identgitattribute.

Si vous voulez mettre SHA-1 de commettre, il n'y a pas hors-the-box solution, mais vous pouvez utiliser clean et smudge commandes de filtergitattribute. Notez que cela affecterait gravement les performances, car après la validation chaque fichier devra être modifié pour refléter la nouvelle validation effectuée.

---

Bien que dit dans d'autres réponses à cette question, vous feriez mieux sur l'intégration de numéro de version dans les fichiers générés lors de la construction, comme par exemple Le noyau Linux et le projet git le font eux-mêmes.

Answer 2

Y compris le commit hash à l'intérieur fichiers inclus dans le commit changerait nécessairement le hachage. Afin de fournir l'intégrité du référentiel via le mécanisme de hachage SHA1, Git ne prend pas (et ne peut pas) supporter une telle fonctionnalité.

Answer 3

ont le hachage git automatiquement inclus dans tous les fichiers de résultats et chiffres.

Vous pouvez transmettre le hachage en tant qu'entrée au programme (par exemple, en tant que variable d'environnement).

Cela seul ne garantit pas que vous passez le hachage bien cependant. Peut-être que vous pouvez écrire un script qui extrait un commit spécifique (par hash ou ref) dans un répertoire spécial (ou temporaire), fait une compilation automatique, puis exécute le programme et passe le hash de commit comme entrée pour le programme.

De cette façon, vous aurez plus confiance que vous obtenez le bon hachage.

Mais tout de même, quelqu'un peut totalement passer n'importe quel hachage bidon et créer des figures trompeuses.

Answer 4

Greg expliqué dans his answer pourquoi ce serait impossible

• Git est un content VCS (versus a revision control or a VCS)
• la touche SHA1 représentent le contenu
• il ne peut pas faire partie du contenu
  En fait, , comme mentionné par Jakub Narębski dans his answer, vous pouvez ajouter le SHA-1 du blob (contenu) lui-même (voir git attributes)
  Comme mentionné dans la question "To put the prefix ?<revision-number> to codes by Git/Svn", Git n'a pas de mécanisme "expansion de mots clés".

ident

Lorsque l'attribut ident est défini pour un chemin, git remplace $Id$ dans l'objet blob avec $Id:, suivi du nom de l'objet blob hexadécimal à 40 caractères, suivi d'un signe dollar $ à la caisse.
Toute séquence d'octets qui commence par $Id: et se termine par $ dans le fichier worktree est remplacé par $Id$ lors de l'enregistrement.

Cela signifie que la solution habituelle est, par some kind of build process, à inclure les informations dont vous avez besoin dans un fichier versionné mais séparé.
Dans votre cas, un fichier contenant la liste de tous les autres fichiers et leur valeur SHA1.
De tels fichiers peuvent être générés à chaque validation (modification de la validation qui vient d'avoir lieu) par exemple.

---

À titre d'exemple d'un fichier séparé, Jefromi points sur le fichier VERSION de Git lui-même, construire par this script

elif test -d .git -o -f .git && 
     VN=$(git describe --match "v[0-9]*" --abbrev=4 HEAD 2>/dev/null) && 
     case "$VN" in 
     *$LF*) (exit 1) ;; 
     v[0-9]*) 
       git update-index -q --refresh 
       test -z "$(git diff-index --name-only HEAD --)" || 
       VN="$VN-dirty" ;; 
     esac 
then 

Answer 5

vous pouvez simplement utiliser le script bash suivant (sauf pour .git/hooks/post-commit)

#!/bin/bash 

# break self-recursiveness 
git log | head -n6 | grep -q 'version.h update' && exit 0 

commit_id=`git log | head -n3 | grep commit` 
v_date=`git log | head -n3 | grep -i date | sed 's|[dD]ate:\s*\(.*\)|\1|'` 

sed -i "s|#define COMMIT.*|#define COMMIT \"${commit_id}\"|" server/version.h 
sed -i "s|#define V_DATE.*|#define V_DATE \"${v_date}\"|" server/version.h 

git commit -m"version.h update" server/version.h 
exit 0 

pour référence, serveur/version.h devrait ressembler à ceci et seront mis à jour après chaque commit:

#ifndef __version_h__ 
#define __version_h__ 

#define COMMIT "commit 2e44e754a9002c99bbf4c09e7827f307d5f0d6f9" 
#define V_DATE "Sat Aug 20 19:35:47 2016 +0300" 

#endif