W Git, jak mogę zapisać bieżący skrót zatwierdzenia do pliku w tym samym zatwierdzeniu

Próbuję tutaj zrobić wymyślne rzeczy z hookami Gita, ale tak naprawdę nie wiem, jak to zrobić (lub jeśli to możliwe).

To, co muszę zrobić, to: w każdym zatwierdzeniu chcę wziąć jego hash, a następnie zaktualizować plik w zatwierdzeniu tym hashem.

Jakieś pomysły?

Poleciłbym zrobić coś podobnego do tego, co masz na myśli: umieszczenie SHA1 w nieśledzonym pliku, generowanym w ramach procesu budowania / instalacji / wdrażania. Jest to oczywiście łatwe do zrobienia ( git rev-parse HEAD > filenamea może git describe [--tags] > filename) i pozwala uniknąć zrobienia czegoś szalonego, na przykład skończenia z plikiem, który różni się od tego, co śledzi git.

Twój kod może następnie odwoływać się do tego pliku, gdy potrzebuje numeru wersji, lub proces kompilacji może uwzględnić te informacje w produkcie końcowym. To ostatnie jest w rzeczywistości sposobem, w jaki sam git otrzymuje numery wersji - proces budowania pobiera numer wersji z repozytorium, a następnie wbudowuje go w plik wykonywalny.

Nie można zapisać aktualnego skrótu zatwierdzenia: jeśli uda Ci się wstępnie obliczyć wartość skrótu przyszłego zatwierdzenia - zmieni się on, gdy tylko zmodyfikujesz dowolny plik.

Istnieją jednak trzy opcje:

1. Użyj skryptu, aby zwiększyć „identyfikator zatwierdzenia” i umieścić go gdzieś. Brzydki
2. .gitignore plik, w którym zamierzasz przechowywać hash. Niezbyt poręczne
3. W pre-commit, zapisz poprzedni hash zatwierdzenia :) Nie modyfikujesz / nie wstawiasz zatwierdzeń w 99,99% przypadków, więc to BĘDZIE działało. W najgorszym przypadku nadal możesz zidentyfikować wersję źródłową.

Pracuję nad skryptem przechwytującym, wrzucę go tutaj 'po zakończeniu', ale nadal - przed wydaniem Duke Nukem Forever :))

Aktualizacja : kod dla .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

Teraz jedyne, czego potrzebujemy, to narzędzie, które konwertuje prev_commit,branchparę na prawdziwy hash zatwierdzenia :)

Nie wiem, czy to podejście może odróżnić scalanie zatwierdzeń od siebie. Niedługo to sprawdzę

Ktoś wskazał mi sekcję „man gitattributes” na ident, która zawiera:

ident

Gdy identyfikator atrybutu jest ustawiony dla ścieżki, git zamienia $ Id $ w obiekcie blob na $ Id :, po którym następuje 40-znakowa szesnastkowa nazwa obiektu blob, po której następuje znak dolara $. Każda sekwencja bajtów, która zaczyna się od $ Id: i kończy na $ w pliku drzewa roboczego, jest zastępowana $ Id $ podczas wpisywania.

Jeśli się nad tym zastanowić, to właśnie robią CVS, Subversion itp. Jeśli spojrzysz na repozytorium, zobaczysz, że plik w repozytorium zawsze zawiera na przykład $ Id $. Nigdy nie zawiera rozszerzenia tego. Dopiero przy kasie tekst jest rozszerzany.

Można to osiągnąć za pomocą filteratrybutu w gitattributes . Musiałbyś podać smudgepolecenie, które wstawia identyfikator zatwierdzenia, i cleanpolecenie, które je usuwa, tak aby plik, w którym jest wstawiony, nie zmienił się tylko z powodu identyfikatora zatwierdzenia.

W związku z tym identyfikator zatwierdzenia nigdy nie jest przechowywany w obiekcie blob pliku; jest po prostu rozszerzony w kopii roboczej. (Właściwie wstawienie identyfikatora zatwierdzenia do obiektu blob stałoby się zadaniem nieskończenie rekurencyjnym. ☺) Każdy, kto klonuje to drzewo, musiałby ustawić atrybuty dla siebie.

Pomyśl poza polem zmian!

wrzuć to do pliku hooks / post-checkout

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

Wersja będzie dostępna wszędzie tam, gdzie jej użyjesz.

Nie sądzę, abyś chciał to zrobić, ponieważ kiedy plik w zatwierdzeniu jest zmieniany, zmienia się również skrót zatwierdzenia.

Pozwólcie, że zbadam, dlaczego jest to trudny problem z wykorzystaniem wewnętrznych elementów git. Możesz pobrać sha1 bieżącego zatwierdzenia przez

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

Zasadniczo uruchamiasz sumę kontrolną sha1 dla wiadomości zwróconej przez git cat-file commit HEAD. Po przeanalizowaniu tej wiadomości od razu pojawiają się dwie rzeczy. Jeden to drzewo sha1, a drugi to czas zatwierdzenia.

Teraz można łatwo zająć się czasem zatwierdzenia, zmieniając wiadomość i odgadując, ile czasu zajmie wykonanie zatwierdzenia lub zaplanowanie zatwierdzenia w określonym czasie. Prawdziwym problemem jest drzewo sha1, z którego można uzyskać git ls-tree $(git write-tree) | git mktree. Zasadniczo robisz sumę kontrolną sha1 dla wiadomości z ls-tree, która jest listą wszystkich plików i ich sumą kontrolną sha1.

Dlatego suma kontrolna sha1 twojego zatwierdzenia zależy od sumy kontrolnej sha1 twojego drzewa, która bezpośrednio zależy od sumy kontrolnej pliku sha1, która zamyka okrąg i zależy od zatwierdzenia sha1. Tak więc masz problem z metodami dostępnymi dla mnie.

Przy mniej bezpiecznych sumach kontrolnych okazało się, że możliwe jest zapisanie sumy kontrolnej pliku do samego pliku przy użyciu brutalnej siły; jednak nie znam żadnej pracy, która wykonałaby to zadanie z sha1. Nie jest to niemożliwe, ale prawie niemożliwe przy naszym obecnym rozumieniu (ale kto wie, może za kilka lat będzie to trywialne). Jednak nadal jest to jeszcze trudniejsze do brutalnej siły, ponieważ musisz zapisać (zatwierdzoną) sumę kontrolną (drzewa) sumy kontrolnej (blob) do pliku.