Něco na ten způsob tam je, když se místo sériového čísla použije (nestandardní) direktiva $UNIXTIME
a na straně serveru se nastaví smudge filtr, který direktivu nahradí za aktuální timestamp. Jiné formáty sériových čísel jsou trochu problém, protože závisí na předchozím stavu – tohle se také může rozbít, pokud se sejdou dva commity v jednu sekundu.
Jsem si prave rikal, ze v GITu je u kazdeho souboru moznost videt, ve kterem commitu byl naposled zmenen. T.j. by nemuselo bejt nemozny vzit z toho datum a spocitat, kolikaty commit to byl v tom dni a udelat "klasicke" cislo typu 2018122003 ve smyslu treti commit ze dne 20.12.2018....
My treba pouzivame na nasich par domen tinydns a jedna z pozitivnich vlastnosti je, ze se clovek nemusi starat o seriova cisla.
Navic, pokud by nekdo chtel vyuzit moznosti GITu naplno a zacal by pouzivat jeho distribuovanost, tak seriova cisla jsou presne mista, kde budou nejsnaz vznikat konflikty... Ikdyz musim priznat, ze predstava, ze X lidi edituje stejnou zonu najednou tak, ze se pri tom muzou poprat, me docela desi .... :-)
Určitě by to tak šlo udělat, asi by to ani nebylo příliš těžké. Já se zatím spokojil s tím, že háček pre-commit
automaticky sériové číslo zvyšuje (v souladu s používaným schématem), takže stačí commitnout poprvé, nechat si vynadat a hned commitnout podruhé. Tohle automatické zvyšování sériového čísla se mimochodem rozbije v červnu 2034, kdy timestamp bude vyšší než sériové číslo utvořené podle YYDDMMnn ;)