Przechodzenie z CVS do Git: odpowiednik $ Id $?

Przeczytałem kilka pytań dotyczących prostych narzędzi do kontroli kodu źródłowego i Git wydawał się rozsądnym wyborem. Mam go uruchomionego i działa dobrze. Jednym z aspektów CVS, który mi się podoba, jest automatyczne zwiększanie numeru wersji.

Rozumiem, że w rozproszonym repozytorium ma to mniejszy sens, ale jako programista chcę / potrzebuję czegoś takiego. Pozwól mi wyjaśnić, dlaczego:

Używam Emacsa. Okresowo przeglądam i szukam nowych wersji plików źródłowych Lisp dla pakietów innych firm. Powiedzmy, że mam plik foo.el, który zgodnie z nagłówkiem ma wersję 1.3; jeśli sprawdzę najnowszą wersję i zobaczę, że jest to 1.143, 2.6 lub cokolwiek innego, wiem, że jestem daleko w tyle.

Jeśli zamiast tego zobaczę kilka 40-znakowych skrótów, nie będę wiedział, który jest później, ani nie mam pojęcia, ile jest później. Absolutnie nienawidziłbym tego, gdybym musiał ręcznie sprawdzać ChangeLogs tylko po to, aby dowiedzieć się, jak bardzo jestem nieaktualny.

Jako programista chcę rozszerzyć tę uprzejmość, tak jak to widzę, na ludzi, którzy używają moich wyników (i może żartuję sobie, że ktoś jest, ale zostawmy to na chwilę). Nie chcę pamiętać, aby za każdym razem zwiększać tę cholerną liczbę, sygnaturę czasową czy coś w tym rodzaju. To prawdziwa PITA i wiem to z doświadczenia.

Więc jakie mam alternatywy? Jeśli nie mogę uzyskać ekwiwalentu $ Id: $, jak jeszcze mogę podać to, czego szukam?

Powinienem wspomnieć, że oczekuję, że użytkownik końcowy NIE będzie miał zainstalowanego Gita, a nawet jeśli to zrobi, nie będzie miał lokalnego repozytorium (w rzeczywistości nie spodziewam się udostępnienia go w ten sposób).

SHA to tylko jedna reprezentacja wersji (aczkolwiek kanoniczna). git describeKomenda oferuje innym i robi to całkiem dobrze.

Na przykład, gdy uruchamiam git describew mojej głównej gałęzi mojego źródła klienta memcached Java , otrzymuję to:

2.2-16-gc0cd61a

To mówi dwie ważne rzeczy:

1. Od wersji 2.2 w tym drzewie było dokładnie 16 zatwierdzeń
2. Dokładny drzewo źródłem mogą być wyświetlane na klonie nikogo innego.

Załóżmy na przykład, że spakowałeś versionplik ze źródłem (lub nawet przepisałeś całą zawartość do dystrybucji), aby pokazać ten numer. Powiedzmy, że była to wersja spakowana 2.2-12-g6c4ae7a(nie wydanie, ale poprawna wersja).

Możesz teraz zobaczyć, jak daleko jesteś w tyle (4 zatwierdzenia) i dokładnie zobaczyć, które 4 zatwierdzenia:

# The RHS of the .. can be origin/master or empty, or whatever you want.
% git log --pretty=format:"%h %an %s" 2.2-12-g6c4ae7a..2.2-16-gc0cd61a
c0cd61a Dustin Sallings More tries to get a timeout.
8c489ff Dustin Sallings Made the timeout test run on every protocol on every bui
fb326d5 Dustin Sallings Added a test for bug 35.
fba04e9 Valeri Felberg Support passing an expiration date into CAS operations.

Do tej pory istnieje wsparcie dla $ Id: $ w Git. Aby włączyć go dla pliku README , należy umieścić "README ident" w .gitattributes . Obsługiwane są symbole wieloznaczne w nazwach plików. Aby uzyskać szczegółowe informacje, zobacz man gitattributes .

To nie jest nierozsądna prośba ze strony OP.

Mój przypadek użycia to:

1. Używam Gita do własnego, osobistego kodu, dlatego nie współpracuję z innymi.
2. Trzymam tam systemowe skrypty Bash, które mogą wejść, /usr/local/bingdy będą gotowe.

Używam trzech oddzielnych maszyn z tym samym repozytorium Git. Byłoby miło wiedzieć, w jakiej "wersji" pliku mam aktualnie dostęp, /usr/local/binbez konieczności ręcznego wykonywania instrukcji "diff -u <wersja repo> <wersja w / usr / local / bin>".

Dla tych z was, którzy są negatywni, pamiętajcie, że istnieją inne przypadki użycia. Nie wszyscy używają Gita do wspólnej pracy z plikami w repozytorium Git będącymi ich „ostateczną” lokalizacją.

W każdym razie sposób, w jaki to zrobiłem, polegał na utworzeniu pliku atrybutów w repozytorium w następujący sposób:

cat .git/info/attributes
# see man gitattributes
*.sh ident
*.pl ident
*.cgi ident

Następnie umieść $ Id $ gdzieś w pliku (lubię to wstawiać po shebangu).

Zatwierdzenie. Zauważ, że to nie powoduje automatycznego rozszerzenia, tak jak się spodziewałem. Musisz ponownie skopiować plik, na przykład

git commit foo.sh
rm foo.sh
git co foo.sh

A potem zobaczysz rozszerzenie, na przykład:

$ head foo.sh
#!/bin/sh

# $Id: e184834e6757aac77fd0f71344934b1cd774e6d4 $

Kilka przydatnych informacji. Jak włączyć ciąg ident dla repozytorium Git? .

Nie jestem pewien, czy to kiedykolwiek będzie w Git. Aby zacytować Linusa :

„Cała koncepcja zastępowania słów kluczowych jest po prostu totalnie idiotyczna. To trywialne zrobienie„ poza ”faktycznym śledzeniem treści, jeśli chcesz je mieć podczas wykonywania drzew wydania jako kulek tar itp.”

Jednak sprawdzenie dziennika jest dość łatwe - jeśli śledzisz gałąź stabilną foo.el, możesz zobaczyć, jakie nowe zatwierdzenia znajdują się w dzienniku gałęzi stabilnej, a których nie ma w Twojej lokalnej kopii. Jeśli chcesz symulować wewnętrzny numer wersji CVS, możesz porównać znacznik czasu ostatniego zatwierdzenia.

Edycja: powinieneś pisać lub używać do tego cudzych skryptów, oczywiście nie rób tego ręcznie.

Jak napisałem wcześniej :

Automatyczne generowanie znaczników identyfikacyjnych, które pokazują rozsądny numer wersji, jest niemożliwe w przypadku narzędzi DSCM, takich jak Bazaar, ponieważ każdy kierunek rozwoju może różnić się od wszystkich innych. Ktoś mógłby więc odnieść się do wersji „1.41” pliku, ale Twoja wersja „1.41” tego pliku jest inna.

Zasadniczo $ Id $ nie ma żadnego sensu w przypadku Bazaar, Git i innych rozproszonych narzędzi do zarządzania kodem źródłowym.

Miałem ten sam problem. Potrzebowałem wersji, która byłaby prostsza niż ciąg skrótu i ​​dostępna dla osób używających tego narzędzia bez konieczności łączenia się z repozytorium.

Zrobiłem to za pomocą haka Git przed zatwierdzeniem i zmieniłem mój skrypt, aby mógł się automatycznie aktualizować.

Opieram wersję na liczbie wykonanych zatwierdzeń. Jest to niewielki przypadek wyścigu, ponieważ dwie osoby mogą zatwierdzić w tym samym czasie i obie myślą, że zatwierdzają ten sam numer wersji, ale nie mamy wielu programistów w tym projekcie.

Na przykład mam skrypt, który sprawdzam, który jest w Rubim i dodaję do niego ten kod - jest to dość prosty kod, więc łatwo jest przenieść na różne języki, jeśli sprawdzasz coś w innym języku (chociaż oczywiście jest to nie będzie łatwo działać z nieobsługiwanymi checkins, takimi jak pliki tekstowe). Dodałem:

MYVERSION = '1.090'
## Call script to do updateVersion from .git/hooks/pre-commit
def updateVersion
  # We add 1 because the next commit is probably one more - though this is a race
  commits = %x[git log #{$0} | grep '^commit ' | wc -l].to_i + 1
  vers = "1.%0.3d" % commits

  t = File.read($0)
  t.gsub!(/^MYVERSION = '(.*)'$/, "MYVERSION = '#{vers}'")
  bak = $0+'.bak'
  File.open(bak,'w') { |f| f.puts t }
  perm = File.stat($0).mode & 0xfff
  File.rename(bak,$0)
  File.chmod(perm,$0)
  exit
end

Następnie dodaję opcję wiersza poleceń (-updateVersion) do skryptu, więc jeśli nazywam go „narzędziem -updateVersion”, wywołuje on po prostu updateVersion dla narzędzia, które modyfikuje samą wartość „MYVERSION”, a następnie kończy pracę (można niech zaktualizuje również inne pliki, jeśli są również otwarte, jeśli chcesz).

Po skonfigurowaniu przechodzę do głowy Gita i tworzę wykonywalny jednowierszowy skrypt bash w .git/hooks/pre-commit.

Skrypt po prostu przechodzi do nagłówka katalogu Git i wywołuje mój skrypt z -updateVersion.

Za każdym razem, gdy sprawdzam, uruchamiany jest skrypt przed zatwierdzeniem, który uruchamia mój skrypt z opcją -updateVersion, a następnie zmienna MYVERSION jest aktualizowana w oparciu o liczbę zatwierdzeń. Magia!

Jeśli posiadanie $ Keywords $ jest dla Ciebie niezbędne, to może powinieneś spróbować zamiast tego spojrzeć na Mercurial ? Ma rozszerzenie hgkeyword, które implementuje to, co chcesz. Mercurial i tak jest interesujący jako DVCS.

Coś, co jest robione z repozytoriami Git, to użycie tagobiektu. Można tego użyć do oznaczenia zatwierdzenia dowolnym ciągiem znaków i można go użyć do oznaczenia wersji. Możesz zobaczyć te tagi w repozytorium za pomocą git tagpolecenia, które zwraca wszystkie tagi.

Łatwo jest sprawdzić tag. Na przykład, jeśli istnieje tag v1.1, możesz sprawdzić ten tag w gałęzi takiej jak ta:

git checkout -b v1.1

Ponieważ jest to obiekt najwyższego poziomu, zobaczysz całą historię tego zatwierdzenia, a także będziesz mógł uruchamiać różnice, wprowadzać zmiany i scalać.

Nie tylko to, ale znacznik pozostaje, nawet jeśli gałąź, w której się znajdował, została usunięta bez scalenia z powrotem do głównej linii.

Jeśli dobrze rozumiem, zasadniczo chcesz wiedzieć, ile zatwierdzeń wydarzyło się w danym pliku od ostatniej aktualizacji.

Najpierw pobierz zmiany w zdalnym źródle, ale nie scalaj ich ze swoją mastergałęzią:

% git fetch

Następnie pobierz dziennik zmian, które zaszły w danym pliku między twoim masteroddziałem a pilotem origin/master.

% git log master..origin/master foo.el

To daje ci komunikaty dziennika wszystkich zatwierdzeń, które miały miejsce w zdalnym repozytorium od czasu ostatniego scalenia origin/masterz master.

Jeśli chcesz tylko zliczać zmiany, prześlij ją do wc. Powiedz w ten sposób:

% git rev-list master..origin/master foo.el | wc -l

Jeśli chcesz, aby ludzie mogli zorientować się, jak bardzo są nieaktualni, Git może ich o tym poinformować na kilka dość łatwych sposobów. Na przykład porównują daty ostatniego zatwierdzenia w swoim bagażniku i Twoim bagażniku. Mogą użyć, git cherryaby zobaczyć, ile zatwierdzeń wystąpiło w twoim pniu, których nie ma w ich.

Jeśli to wszystko, czego chcesz, szukałbym sposobu, aby podać to bez numeru wersji.

Poza tym nie zawracałbym sobie głowy okazaniem uprzejmości nikomu, chyba że jesteś pewien, że tego chcą. :)

Aby zastosować rozszerzenie do wszystkich plików we wszystkich podkatalogach w repozytorium, dodaj .gitattributesplik do katalogu najwyższego poziomu w repozytorium (tj. Tam, gdzie normalnie umieszczasz .gitignoreplik) zawierający:

* ident

Aby zobaczyć, jak to działa, musisz najpierw skutecznie wyrejestrować plik (i), na przykład usunąć je lub edytować w jakikolwiek sposób. Następnie przywróć je za pomocą:

git checkout .

I powinieneś zobaczyć $Id$zastąpiony czymś takim:

$Id: ea701b0bb744c90c620f315e2438bc6b764cdb87 $

Od man gitattributes:

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.

Ten identyfikator będzie się zmieniał za każdym razem, gdy zostanie zatwierdzona nowa wersja pliku.

Identyfikatory RCS są dobre dla projektów jednoplikowych, ale w przypadku każdego innego $ Id $ nic nie mówi o projekcie (chyba że wymusisz fikcyjne wpisy do fałszywego pliku wersji).

Wciąż może być ciekaw, jak uzyskać odpowiedniki $ Author $, $ Date $, $ Revision $, $ RCSfile $ itd. Na poziomie pliku lub zatwierdzenia (jak je umieścić tam, gdzie są niektóre słowa kluczowe pytanie). Nie mam odpowiedzi na te pytania, ale widzę wymóg ich aktualizacji, zwłaszcza gdy pliki (teraz w Git) pochodzą z systemów kompatybilnych z RCS (CVS).

Takie słowa kluczowe mogą być interesujące, jeśli źródła są dystrybuowane oddzielnie od dowolnego repozytorium Gita (to też robię). Moje rozwiązanie jest takie:

Każdy projekt ma własny katalog, aw katalogu głównym projektu mam plik tekstowy o nazwie, .versionktórej zawartość opisuje aktualną wersję (nazwa, która będzie używana podczas eksportowania źródeł).

Podczas pracy nad kolejną wersją skrypt wyodrębnia tę .versionliczbę, deskryptor wersji Git (np. git describe) I monotoniczny numer kompilacji w .build(plus host i datę) do automatycznie wygenerowanego pliku źródłowego, który jest powiązany z ostatecznym programem, dzięki czemu można znaleźć z jakiego źródła i kiedy zostało zbudowane.

Opracowuję nowe funkcje w oddzielnych gałęziach, a pierwszą rzeczą, którą robię, jest dodanie n(dla „następnego”) do .versionciągu (wiele gałęzi pochodzących z tego samego katalogu głównego używałoby tej samej .versionliczby tymczasowej ). Przed wydaniem decyduję, które gałęzie połączyć (mam nadzieję, że wszystkie mają takie same .version). Przed wykonaniem scalenia aktualizuję .versiondo następnego numeru (aktualizacja główna lub drobna, w zależności od połączonych funkcji).

Jeśli chcesz git commit informacji dostępnej w kodzie, to mają zrobić krok w pre-build, aby ją tam. W bash dla C / C ++ może to wyglądać mniej więcej tak:

prebuild.sh

#!/bin/bash
commit=$(git rev-parse HEAD)
tag=$(git describe --tags --always ${commit})
cat <<EOF >version.c
#include "version.h"
const char* git_tag="${tag}";
const char* git_commit="${commit}";
EOF

z version.hwyglądem:

#pragma once
const char* git_tag;
const char* git_commit;

Następnie, gdziekolwiek potrzebujesz tego w swoim kodzie #include "version.h"i referencjach git_taglub git_commitw razie potrzeby.

A twój Makefilemoże mieć coś takiego:

all: package
version:
  ./prebuild.sh
package: version
  # the normal build stuff for your project

Ma to tę zaletę, że:

• uzyskiwanie aktualnie poprawnych wartości dla tej kompilacji, niezależnie od rozgałęziania, łączenia selekcji i tym podobnych.

Ta implementacja prepublish.shma wady:

• wymuszanie ponownej kompilacji, nawet jeśli opcja git_tag/ git_commitnie uległa zmianie.
• nie bierze pod uwagę lokalnych zmodyfikowanych plików, które nie zostały zatwierdzone, ale mają wpływ na kompilację.
  • użyj, git describe --tags --always --dirtyaby złapać ten przypadek użycia.
• zanieczyszcza globalną przestrzeń nazw.

Hodowca, prebuild.shktóry mógłby uniknąć tych problemów, jest pozostawiony jako ćwiczenie dla czytelnika.

Zgadzam się z tymi, którzy uważają, że zastępowanie tokenów należy do narzędzi do budowania, a nie do narzędzi do kontroli wersji.

Powinieneś mieć jakieś automatyczne narzędzie do ustawiania identyfikatorów wersji w źródłach w momencie oznaczania wydania.

Nazwy znaczników i inne powiązane informacje mogą być teraz automatycznie edytowane bezpośrednio w plikach przez Git za pomocą export-substfunkcji gitattributes(5). To oczywiście wymaga użycia git archivedo tworzenia wydań i tylko w wynikowym pliku tar będą widoczne zmiany po podstawieniu.

Na przykład w .gitattributespliku umieść następującą linię:

* export-subst

Następnie w plikach źródłowych możesz dodać taką linię:

#ident  "@(#)PROJECTNAME:FILENAME:$Format:%D:%ci:%cN:%h$"

I tak będzie wyglądać w wersji stworzonej na przykład przez git archive v1.2.0.90 :

#ident  "@(#)PROJECTNAME:FILENAME:HEAD -> master, tag: v1.2.0.90:2020-04-03 18:40:44 -0700:Greg A. Woods:e48f949"

Skoro używasz Emacsa, możesz mieć szczęście :)

Trafiłem na to pytanie przez przypadek, a także przez przypadek trafiłem na Lively kilka dni temu, pakiet Emacsa, który pozwala na posiadanie żywych fragmentów Emacsa Lispa w twoim dokumencie. Szczerze mówiąc nie próbowałem, ale przyszło mi do głowy, czytając to.

Pochodzę także z SCCS, RCS i CVS ( %W% %G% %U%).

Miałem podobne wyzwanie. Chciałem wiedzieć, w jakiej wersji znajduje się fragment kodu w każdym systemie, na którym jest uruchomiony. System może, ale nie musi być podłączony do żadnej sieci. System może mieć zainstalowany Git lub nie. W systemie może być zainstalowane repozytorium GitHub lub nie.

Chciałem tego samego rozwiązania dla kilku typów kodu (.sh, .go, .yml, .xml itp.). Chciałem, aby każda osoba bez znajomości Git lub GitHub mogła odpowiedzieć na pytanie „Jakiej wersji używasz?”

Tak więc napisałem coś, co nazywam opakowaniem wokół kilku poleceń Gita. Używam go do oznaczenia pliku numerem wersji i kilkoma informacjami. To rozwiązuje moje wyzwanie. To może ci pomóc.

https://github.com/BradleyA/markit

git clone https://github.com/BradleyA/markit
cd markit

Aby rozwiązać ten problem dla siebie, utworzyłem mały „hack” jako punkt zaczepienia po zatwierdzeniu:

echo | tee --append *
git checkout *

Bardziej szczegółowo udokumentowane w tym poście na moim blogu .