Jak si udržovat historii /etc v gitu (diskuse)

[KS]

Díky za článek, fakt dobrý. O verzování konfiguráků jsem párkrát uvažoval. Mohlo by se to dostat do distribucí jako běžná věc.

[Georgo10]

Taktéž děkuji -- O nějaké záloze /etc jsem vždycky uvažoval, ale nápad použít verzovací systém, mi hlavou nebleskl Určitě vyzkouším, ještě jednou díky

[Josef Kufner]

To by nemuselo být špatné... ale jsem moc líný, takže by to chtělo napojit na apt, aby se to ukládalo samo. Nejlépe vždy před a po nějaké instalaci/upgrade/čemkoliv.

[Petr "Glubo" Sýkora]

Naprosto souhlasím, sám přemýšlím, jak nejlépe to napojit na portage, zatím to řeším cronem daily (uvedený kombo příkaz je copy&paste z mého cronu), což mi přijde jako dostatečné, nikoliv však ideální řešení. Dokonce se git chová tak, že pokud není nic ke commitnutí, ignoruje commit a tudíž nevzniká tisíce zbytečných commitů, což mne mile překvapilo

[David Watzke]

Mně se /etc zálohuje každej den ráno na server a docela to stačí...

[Josef Kufner]

Ono tady jde spíš o tu historii a možnost kouknout se, co se vlastne kdy změnilo. V tom mají nástroje na správu verzí precejen nějaké ty výhody oproti hromádce adresářů...

[Petr "Glubo" Sýkora]

No já si zase mohu jedním příkazem vypsat histrorii změn v jednom souboru/adresáři pomocí git-whatchanged -p soubor, což mi vypíše kdy se ten soubor měnil a diffy jednotlivých změn.

[disorder]

a komu venujes ten /etc/shadow kazde rano?

[Käyttäjä 11133]

A není to jedno, jaká je šance že ty hashe rozlousknou? Moc velká asi ne. Teda pokud nemá lehce uhodnutelná hesla. Nebo útočník pár s390 ve sklepě :)

[disorder]

radsej poloz otazku, aka sanca bude zajtra/o tyzden/etc...

[Käyttäjä 11133]

No správný paranoik mění hesla každý týden

[disorder]

a to je nejaka prekazka tomu, ze ti to niekto zajtra moze rozlusknut za 30 sekund?

[David Watzke]

Teda pokud nemá lehce uhodnutelná hesla

nbusr123

[David Watzke]

Je to u Zdendy na serveru (klenot.cz) a adresář backup má přístupový práva 700. Můžu být v klidu

[disorder]

no bodaj by si tomu nedal 700, to uz by bol naprosty vysmech bezpecnosti :D

v kazdom pripade by si z toho mohol mazat hashe, to nie je problem...

[Josef Kufner]

A nebo to během přenosu na server šifrovat.

[disorder]

ja by som to v plaintexte neukladal ani na vlastny server...

[onion]

Jeste doplnim, ze prikazem

git-config color.diff auto

bude vystup z git-whatchanged (a vsech ostatnich diffu) pekne barevny. Chvilku mi trvalo nez jsem na to prisel, takze tim treba nekomu ulehcim praci :D

[User682]

zdravim,

git nejaky mesic pouzivam. Skvely nastroj. Ale par veci jsem nerozlousknul.

Nepouzivate nahodou nekdo git na vice projektu, ktere maji zcasti stejny zaklad ?

Neco delam asi spatne nebo nechapu filosifii uzivani gitu. Nebo je to mozna mimo moznosti gitu.

Dam priklad:

testuji ruzne kernely a pripadne hledam zmeny a chyby. Dovedu si vyexportovat aktualni zdrojaky, najit zmeny, udelat nejaky bisect, pripadne si zmergovat zmeny.

Ale zda se mi trochu neefektivni mit specielne na kernel 2 ruzna uloziste.

Mam:

- linus-uv kernel

- mm-kernel

- thinkpad-acpi

A ted jak si usporadat uloziste (repositare) ?

Mit vse v jednom reposiraci nebo mit 3 repositare ?

Jak na to ? A jak se pripadne prepinat mezi repositari a vyexportovat si konkretni zdrojaky k danemu datu ?

Tato vec mi vcelku brani dostat se dale.

Jak by jste toto resili? Predem diky.

Pavel Kysilka

[michich]

Nevím, jestli to má cenu dělat i s -mm kernely, protože Andrew Morton je udržuje pomocí quiltu a git strom je až sekundární reprezentace. Já je tahám zvlášť pomocí ketchupu.

Ale s tím thinkpad-acpi jsem si to teď zkusil. Vlezu do adresáře, kde mám Linusův strom a pár svých místních větví. Řeknu gitu, že budu chtít sledovat další vzdálený repozitář:

git-remote add ibm-acpi \
git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git

Stáhnu si ho k sobě:

git-fetch ibm-acpi

Podívám se, jaké větve tam mají:

git-branch -r

Budu chtít pracovat s větví devel, tak si udělám místní větev, která jí bude odpovídat (a git-pull mi ji bude umět aktualizovat):

git-branch --track ibm-acpi ibm-acpi/devel

Přepínám se pomocí git-checkout.

Nevím, jestli je to ideální způsob. Jestli to někdo děláte jinak a lépe, tak by mě to zajímalo.

[User682]

Co se tyce mm-kernelu, tak bych rad redukoval primerene traffic a nerad bych tahal cele tarbally. Vcelku je pro me mm-kernel dulezity - hodne chyb se najde drive nez v linus-kernelu.

Nicmene podle Vaseho navodu pujde tahat primo z git:// zdroje mm-kernel.

Kazdopadne diky, s timto se pohnu hodne dale. Kdybych prisel na neco zajimaveho nebo vylepseneho, tak dam vedet.

Pavel Kysilka

[michich]

Ten ketchup, co na -mm používám, je docela chytrý. Netahá pokaždé znovu celé tarbally. Když už má nějakou předchozí verzi staženou, tak tahá diffy. Ve Fedoře i v Debianu se balíček jmenuje ketchup.

[Jiří Lisický]

Na jednoduché verzování konfiguráků používám systém rcs. Řekl bych, že balíček bude součástí téměř všech distribucí.

[Petr Tomášek]

Na tohle mi prijde jako idealni svn. Git ma podle me smysl az ve chvili, kdy je potreba predavat changesety z jednoho repositare do druheho...

[Petr "Glubo" Sýkora]

Asi jsem zaslepen buhví čím, ale v čem je svn lepší na tento úkol, než git? Zrovna u takto "nenáročného" úkolu mi přijde, že by svn mělo být srovnatelně vhodné.

[Josef Kufner]

Mno, spíš naopak. Git je vhodnější, protože není potřeba vytvářet repositář.

[Jiří (BoodOk) Kadeřávek]

Jeno pro upřesnění. Jedná se totiž stejně jako u např. Bazaar o tzv. decentralizovaný/distribuovaný systém správy verzí, narozdíl od centralizovaného systému jakými je např. SVN, CVS a další.

http://en.wikipedia.org/wiki/Revision_control
http://en.wikipedia.org/wiki/Git_(software)
http://en.wikipedia.org/wiki/Bazaar_(software)
http://en.wikipedia.org/wiki/Subversion_(software)

[Josef Kufner]

Ono ani nejde o to, že by byl decentralizovaný -- to jen souvisí s tím, že součástí pracovního adresáře je i kompletní repositář. Klíčovou vlastností gitu je to, že necpe do každého adresáře bordel jako to dělá svn a cvs. Protě bude jen /etc/.git a to je všecko. Ony adresáře .svn by dělaly problémy při změnách adresářů balíčkovacím systémem -- adresář není prázdný a tak ho nelze smazat...

[Jiří (BoodOk) Kadeřávek]

Takhle máš repository spolu s projektem. A naučit se pracovat a ovládat systém správy verzí není úplně triviální záležitost, tudíž rozhodně s ohledem na portabilitu u menších projektů (rozuměj 1-5 lidí) preferuji decentralizovaný model. Případné merge nejsou navíc v takové skupině až tak složité.