Obdoba RCS $Log$ v gitu

[iq8]

Dobrý den
Dlouho jsem používal RCS pro ukládání verzí souborů, upravuji převážně skripty tak mi to stačí.
Teď pracuji na trošku větší skupině skriptů které jsou provázané.
Řekl jsem si, že se zkusím přiučit git.

Nicméně jsem nenašel, jestli je možné pomocí gitu vkládat do těla souboru informace o verzi.
V RCS se to dělá pomocí $Log$ -> toto je následně nahrazeno informací o verzi souboru.
Je možné něco obdobného i pomocí gitu?

Předem děkuji za odkaz nebo radu jak toto řešit.

[Reklama]

[Inkvizitor]

V Gitu soubor žádnou verzi nemá. "Verzi" má commit a ta "verze" je hash a ten commit může být zároveň odkazovaný z desítek větví a tagů najednou a to v lokálních nebo i vzdálených repozitářích. Tu RCS logiku, pokud můžeš, v Gitu neřeš a ideálně na ni zapomeň úplně.

[Trupik]

Git je decentralizovaný systém takže ak na jednej strane vznikne verzia "1.1", aj inde môže vzniknúť úplne iná verzia "1.1". Ktorá potom je tá správna "1.1"? Preto git nemá verzie, len hashe. A tie nemá zmysel zapisovať do súboru, pretože ak do súboru zapíšeš jeho vlastný hash, zmeníš tým jeho hash a môžeš rátať hash odznova - donekonečna.
...
Čo vlastne týmto spôsobom (zápisom verzie súboru do samého seba) potrebuješ dosiahnuť? Aký problém to rieši? Akú výhodu to poskytuje?

[kimec]

Najprv podstatne veci na zaciatok. Tieto dva body vysvetluju absolutnu esenciu, co je a ako funguje git. Decentralizovanost, vetvy, tagy, remoty a ine radosti su pekne, ale nie su podstatou gitu.

• git je content addressable suborovy system (teda nie, nie je to nastroj na verzionovanie.  "verzionovanie" v gite, ak ho tam silou mocou chcete hladat, je len vedlajsi produkt)
• "vsetko", co sa do gitu ulozi, sa uklada do struktury s nazvom Merkle Directed Acyclic Graph

Tieto dva body vysvetluju fundamentalne fungovanie gitu a co sa od neho da ocakavat. Ak vas to zaujima a nastudujete si vyznam oboch bodov, budete naozaj rozumiet gitu.
Napriklad z toho vyplyva, ze technicky nemozete zakomitovat subor tak, aby v sebe obsahoval nejaku notaciu verzie, ci uz nejaku referenciu alebo hash komitu, ktory prave pripravujete.

K vasemu poteseniu existuje ale sposob, ako dosiahnut nieco skoro podobne. Nech sa paci. Blizsie sa k tomu, co chcete, nedostanete.

https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#_keyword_expansion

Ceresnicka:

SVN- or CVS-style keyword expansion is often requested by developers used to those systems. The main problem with this in Git is that you can’t modify a file with information about the commit after you’ve committed, because Git checksums the file first. However, you can inject text into a file when it’s checked out and remove it again before it’s added to a commit. Git attributes offers you two ways to do this.

[Ovrscout]

Pokud se chces priucit git doporucuju publikaci progit, je tam celkem srozumitelne vysvetleno jak to funguje a co od toho lze čekat (hlavně kapitola 1.3). Git tak trochu mění pohled na verzování místo verzování souborů, na verzování projektu. Možná z počátku to zní podivně, ale díky nástrojům které má se s tím pracuje dobře, např "blame" a velmi silná práce s větvemi. Číslování verzí je ale tak trochu vyjímka

Dobrá ale trochu starší verze knihy v češtině (s některými, .. trochu zvláštními překlady pojmů) https://knihy.nic.cz/
Nebo v originale(novejsi) https://www.git-scm.com/book/en/v2

Pokud jsi pročet alespoň pár prvních kapitol tak už asi odpovědi znáš ,ale :
Commit je určen tzv hashem, jeho zkrácená podoba se dá použít pro určení verze. Ke commitu (vlastně k tomu hashi) se dá přilepit pěkné číslo verze pomocí štítku - "tag". Ale automatické číslování souborů ve smyslu 1.1,1.2 atd se tu moc nepoužívá. Je to hlavně proto že git je hodně silný v používání větví "branch" a to i dočasných, kde je pak s automatickým číslováním poměrně problém.

Nicméně, pokud je to potřeba git umožnuje spouštět skripty při různých příležitostech, commit, checkout,.. a je tak možné provádět různá kouzla(Git Hooks).

[Reklama]

[Iq8]

Děkuji za reakce. Asi jsem se na to koukal špatně.
Vyrábím sadu skriptů.  Jsou na vice počítačích. 
Podle verze uvnitř jsem vždy poznal jaká je nasazená verze.
Teď mi to chybí. Nemáte nějaký nápad jak toto řešit?

[kimec]

Podle verze uvnitř jsem vždy poznal jaká je nasazená verze.
Teď mi to chybí. Nemáte nějaký nápad jak toto řešit?

Tu je to cierne na bielom - potrebujete pouzit filtre, ktore postprocesnu skripty pri checkoute do worktree. Znovu posielam ten isty link
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes#_keyword_expansion

Mozete mat jeden centralny remote odkial si jednotlive stroje budu pullovat ako down streamy. Kedze komitovat nebudu ku konfliktom nejdojde a mozete fast forwardovat. pull/fetch mozete robit cez cron. pri checkoute cez filter pridate datum alebo commit hashu alebo oboje.

[Trupik]

Děkuji za reakce. Asi jsem se na to koukal špatně.
Vyrábím sadu skriptů.  Jsou na vice počítačích. 
Podle verze uvnitř jsem vždy poznal jaká je nasazená verze.
Teď mi to chybí. Nemáte nějaký nápad jak toto řešit?

Ja osobne zisťujem verziu za behu spustením príkazu "git rev-parse HEAD":

Kód: [Vybrat]

#!/bin/bash
VERSION=`git rev-parse HEAD`
echo $VERSION
...
To ale funguje len ak je working dir clean. Okrem toho takto získaná "verzia" slúži len pre rozhodnutie či je rovnaká ako verzia niekde inde a neslúži na zisťovanie, ktorá verzia je aktuálnejšia. To by asi šlo dosiahnuť iným príkazom - treba pozrieť man page.

[Iq8]

Omlouvám se čtu to na mobilu. Přehlédl jsme to. Děkuju to bude ono.

[kimec]

Nech sluzi. Dajte vediet ako to dopadlo. Filtre som zatial nepotreboval, ale evidentne su uzitocne prave na take veci ako chete robit.

[Inkvizitor]

Děkuji za reakce. Asi jsem se na to koukal špatně.
Vyrábím sadu skriptů.  Jsou na vice počítačích. 
Podle verze uvnitř jsem vždy poznal jaká je nasazená verze.
Teď mi to chybí. Nemáte nějaký nápad jak toto řešit?

Pokud to je na Linuxu, tak proč ne klasicky balíčkem? Verze (celého balíčku) bude v metadatech.

[Ovrscout]

K radám ostatních připojím že by mohlo dobré použít ty git hooks, aby po commitu/checkoutu vytvořili soubor který bude obsahovat hash commitu, případně název větve. Ten soubor by nebyl přímo součástí commitu (.gitignore), a případně by ho bylo možno includovat z těch skriptů pokud bys to potřeboval vypsat skriptem. Mělo by to být jednodušší něž použití filtrů a s obdobným výsledkem.

Taky by šlo použít pro deployment samotný git (případně ve spolupráci s hook scripty) a zjišťovat příkazem (viz trupik).

Případně se dá použít opačná logika. Ve chvíli kdy se rozhodneš uvolnit verzi tak spustíš nějaký vlastní skript s případným "pěkným" číslem verze jako parametrem  - nebo si na to napíšeš logiku do skriptu. Zkontroluje se že je workingdir čistý, a číslo verze se přilepí jako štítek k commitu, pak se vytvoří se balíček pro deployment. Součástí přípravy může být právě "vypálení" označení verze včetně hashe do některého ze souborů. Balíček se uloží někam bokem, a případně se rozdistribuje kam je potřeba. Je mi jasné že na menší věci je to tak trochu kanón na vrabce. Ale zase se to může hodit pokud jsou v pracovním adresáři i nějaké "pomocné" či konfigurační soubory které by se neměli dostat ven, nebo naopak pro deploy je potřeba je nahradit jinými. A mít pěkně připravené balíčky(třeba zip soubory) má něco do sebe.

[kimec]

K radám ostatních připojím že by mohlo dobré použít ty git hooks, aby po commitu/checkoutu vytvořili soubor který bude obsahovat hash commitu, případně název větve. Ten soubor by nebyl přímo součástí commitu (.gitignore), a případně by ho bylo možno includovat z těch skriptů pokud bys to potřeboval vypsat skriptem. Mělo by to být jednodušší něž použití filtrů a s obdobným výsledkem.

Len ci bude git commit hook naozaj jednoduchsi ako tieto dva smudge/clean filtre?

Filtre menia placeholder @VER@ na @VER: 4987f2d@ tak, ze sa vypali priamo do skriptu pri checkout-e.
(Navyse clean filter sa da vynechat, pokial bude repo na jednotlivych strojoch namiesto fast-forward mergu hard resetovane na remote tracking upstream, t.j. git fetch && git reset --hard @{u} && git checkout -f)

Kód: [Vybrat]

$ echo "Zaciatok definicie filtrov"
Zaciatok definicie filtrov
$ git config filter.verzia.smudge 'sed -e "/@VER@/{ s/@VER@/@VER: %h@/g; s/.*/git log --pretty=\"&\" -1/e }"'
$ git config filter.verzia.clean 'sed -e "s/@VER: [[:alnum:]]\{7\}@/@VER@/g"'
$ echo "*.py filter=verzia" >> .gitattributes
$ echo "Koniec definicie filtrov"
Koniec definicie filtrov
Overenie funkcnosti

Kód: [Vybrat]

$ echo -e "# Verzia @VER@\nprint 'Tato verzia je @VER@'" > example.py
$ git add .
$ git commit -m 'Pridane filtre pre python'
$ rm example.py
$ git checkout example.py
$ python example.py
Tato verzia je @VER: 4987f2d@
$ cat example.py
# Verzia @VER: 4987f2d@
print 'Tato verzia je @VER: 4987f2d@'
$ git status -s
$ echo "Clean filter funguje"
Clean filter funguje


[Ovrscout]

K radám ostatních připojím že by mohlo dobré použít ty git hooks, aby po commitu/checkoutu vytvořili soubor který bude obsahovat hash commitu, případně název větve. Ten soubor by nebyl přímo součástí commitu (.gitignore), a případně by ho bylo možno includovat z těch skriptů pokud bys to potřeboval vypsat skriptem. Mělo by to být jednodušší něž použití filtrů a s obdobným výsledkem.

Len ci bude git commit hook naozaj jednoduchsi ako tieto dva smudge/clean filtre?

Filtre menia placeholder @VER@ na @VER: 4987f2d@ tak, ze sa vypali priamo do skriptu pri checkout-e.
(Navyse clean filter sa da vynechat, pokial bude repo na jednotlivych strojoch namiesto fast-forward mergu hard resetovane na remote tracking upstream, t.j. git fetch && git reset --hard @{u} && git checkout -f)

Kód: [Vybrat]

$ echo "Zaciatok definicie filtrov"
Zaciatok definicie filtrov
$ git config filter.verzia.smudge 'sed -e "/@VER@/{ s/@VER@/@VER: %h@/g; s/.*/git log --pretty=\"&\" -1/e }"'
$ git config filter.verzia.clean 'sed -e "s/@VER: [[:alnum:]]\{7\}@/@VER@/g"'
$ echo "*.py filter=verzia" >> .gitattributes
$ echo "Koniec definicie filtrov"
Koniec definicie filtrov
Overenie funkcnosti

Kód: [Vybrat]

$ echo -e "# Verzia @VER@\nprint 'Tato verzia je @VER@'" > example.py
$ git add .
$ git commit -m 'Pridane filtre pre python'
$ rm example.py
$ git checkout example.py
$ python example.py
Tato verzia je @VER: 4987f2d@
$ cat example.py
# Verzia @VER: 4987f2d@
print 'Tato verzia je @VER: 4987f2d@'
$ git status -s
$ echo "Clean filter funguje"
Clean filter funguje


moc pěkné a jednodušší něž bych čekal

[iq8]

Dobrý večer
Tak jsem si s tím trochu hrál. A je pravda, že je potřeba změnit myšlení.
Je to jako přechod od Newtona k Einsteinovi. Git je takový dost relativistický.
Nicméně jsem našel pro případné zájemce toto https://github.com/turon/git-rcs-keywords.
Já o sice nepoužiji, ale třeba se to bude hodit někomu jinému.

Vyhrál návrh kolegy Ovrscout. Vytvořil jsem si skript, který to zabalí a očísluje.
Potom se to publikuje na místo odkud se to bere pro nasazení.
Místo publikace je vztažná soustava od které se bere číslování verzí.

Děkuji za pomoc a přeji hezký zbytek víkendu.