Git - optimalizace vykonu

Jan Kasprzak kas na fi.muni.cz
Pondělí Leden 12 13:46:43 CET 2009


	Zdravim,

snazim se pouzit git pro jeden projekt a myslim si, ze by mohl byt
jeste o neco rychlejsi. Popisu zpusob pouziti:

- mam jednu repository kde obcas nekdo neco zmeni.
- chce-li promitnout zmenu jinam (do "produkcniho" prostredi :-), delam
	nasledujici:

	1. git add -A
	2. git commit -a
	3. git push .../master.git
	4. v "produkcnim" prostredi: git pull (coz kopiruje data z master.git)

- volani gitu mam ve skriptu a kazdy krok merim jak dlouho zabere.

Zatim se zda, ze netrivialni mnozstvi casu (> 1 sekundu) bere
prekvapive krok 2 (commit) a jeste vic krok 4 (pull). Na docela
rychlem serveru commit jednoho souboru treba ted vzal 9 sekund
a ten pull 12 sekund. A pritom krok 1 ktery vlastne musi projit
celou checkoutovanou strukturu a podivat se jestli se nekde neco
nezmenilo, bere jednu vterinu nebo i mene. Casto se cela akce (body 1.-4.)
vejde do jedne vteriny, ale nekdy take trva dost dlouho.

	Moje predstava je, ze mam ty repository vic "zapakovane"
nez je treba, a ze git musi u commitu rozpakovavat ty predchozi verze
z nejakych jinych objektu, aby zjistil, co se kde zmenilo. Ale nevim
jak gitu rict "drz si vsechny aktualni verze jako samostatne soubory".
Zatim jsem nastavil gc.auto na 0, aby se mi nekdy nepoustelo
garbage collection (a hodlam poustet "git gc" z nocniho cronu).
	
	Co byste poradili? [ META: nesnazte se mi radit zmeny workflow;
zde jsem popsal jen minimalni stav, workflow menit v teto fazi nemuzu;
jde mi fakt jen o to jak zrychlit vyse uvedena volani gitu ]

	Diky,

-Y.

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
>>  If you find yourself arguing with Alan Cox, you’re _probably_ wrong.  <<
>>     --James Morris in "How and Why You Should Become a Kernel Hacker"  <<



Další informace o konferenci Linux