Dotaz: Git - oznámení o editaci souboru

[guner]

Zdravím Chtěli bychom v práci nasadit git, ale potřebovali bychom aby centrální repositář nějak nesl informaci o tom, že nějaký uživatel již tento soubor edituje.

Čili já na svém stroji začnu editovat soubor, na server se pošle informace, že tento soubor mám editovaný. Kolega na druhém stroji začne editovat ten samý soubor a právě teď by mu mělo vyskočit nějaké oznámení, že tento soubor někdo jiný edituje. Jenom aby věděl, že není sám.

Bude to náhrada Team Foundation Server, který spoustu věcí neumí a zamykání souborů je nežádoucí, ale aspoň se ví, že jej někdo edituje.

Jde něco takového udělat v gitu?

---

---

Odpovědi

[eagle.metawerzum]

Nejde. Git je distribuované verzování a to nic takového nepodporuje a ani nepotřebuje by design.

[NN]

Otazka je proc vubec neco takoveho delat? Kolega muze v klidu editovat stejny soubor a vubec se nemusi starat o to co dela nekdo jiny. Git ho v cas upozorni sam.

[cronin]

Otazka je proc vubec neco takoveho delat?

Súhlasím, že toto je kľúčová otázka, ktorú by mal opytujúci sa zodpovedať. Pravdepodobne tak zistí, že zdroj jeho problému, ktorý sa snaží takto riešiť, leží mimo akéhokoľvek VCS; tam ho treba aj riešiť.

Ak je opytujúci sa stále presvedčený, ze požadovanú funkcionalitu potrebuje, mal by sa poobzerať po iných VCS. Určite by nemali byť distribuované, ale centralizované, pravdepodobne s kategórie "enterprise". Napr. Perforce núti používateľa otvoriť súbor na editáciu pred jeho zmenou, pričom táto informácia sa cez workspace prenáša na server.

Pragmaticky vzaté, vývojári budú nasadenie Perforce v roku 2016 tak nenávidieť -- podotýkam, že spolu so strojcom tejto myšlienky -- že začnú používať git-p4(1), a celá snaha o sledovanie paralelných modifikácií bude márna.

[VM]

To není věc verzovacího systému, ale editoru - ten by měl při editaci poslat broadcast ostatním uživatelům, a broadcasty také případně sledovat a varovat uživatele. A jak se píše nahoře, GIT je určený k tomu, aby více lidí stejný soubor editovat mohlo.

[AraxoN]

Git toto riešiť už z princípu nepotrebuje. Každý vývojár ma svoju lokálnu kópiu repozitára a v nej nepotrebuje riešiť zamykanie, pretože mu tam nechodia dvaja ľudia naraz. Každý vývojár teda tvorí vlastný strom commitov, ktoré si raz za čas navzájom zlúčia (merge) podľa potreby.

Skoro to vyzerá, ako keby ste chceli prejsť na Git ale zároveň zostať pri postupoch z CVS/SVN. Silne to nedoporučujem - výsledkom bude systém, ktorý skombinuje nevýhody oboch prístupov.

[Ruža Becelin]

Pokud je potreba zamykat soubory (vetsinou kvuli nemergeovatelnym typum), je vhodnejsi na tohle pouzit SVN a Git pouzit na zbytek...

[xkucf03]

S tímhle přístupem by se všude používalo SVN, protože zamykání se čas od času hodí na každém projektu. Dneska to musíš řešit tak, že za ostatními zajdeš a řekneš: „teď si pracujte na něčem jiném, jdu refaktorovat“. Kdyby existoval vhodný nástroj, tak by to ušetřilo práci – a není důvod kvůli tomu používat centralizovaný systém místo distribuovaného. Spíš by se ty distribuované mohly něco přiučit od SVN.

[Ruža Becelin]

Proto je vhodne pouzivat oba systemy vedle sebe, s tim, ze se to da propojit v pripade potreby pres git-svn

[xkucf03]

Přesně o tomhle jsem taky přemýšlel, ale ještě jsem to nenapsal

Chtělo by to nástroj, který hlídá (přes inotify) změny v souborech a odešle na server informaci o těch editovaných a server ji přepošle všem ostatním vývojářům – takže můžeš změny včas odložit a počkat, až práci dokončí kolega.

Takový nástroj by šel použít s libovolným verzovacím systémem a libovolným editorem. Případně by mohl existovat i doplněk do editoru, který zprávu odešle ještě než soubor uložíš, ale to není úplně nutné.

[dustin]

Běžně se stává, že více vývojářů udělá změnu v jednom souboru - typicky jeden něco do souboru přidává (dělá na něm), zatímco druhý něco jinde přejmenuje a vede to na malou (jednořádkovou) změnu v daném souboru. Git to bez problémů zmerguje, není potřeba zamykat celý soubor. Ke konfliktům dochází jen málokdy a zpravidla je lze snadno opravit, pokud se často commituje a merguje/rebasuje.

[xkucf03]

Děje se oboje – hodně změn projde hladce, ale některé ne. A to si pak říkáš, že by bylo lepší počkat a lépe si naplánovat práci, než do toho vrtat současně s někým jiným.

[dustin]

Jistěže se v týmu tyhle věci musí komunikovat a dva lidi nebudou současně dělat větší změny ve stejných souborech. Samozřejmě se stává, že některé změny odložím, až daný kolega commitne své změny, které by vedly k větším konfliktům. V praxi se ukazuje, že stačí používat selský rozum a komunikovat.

Pokud si syslím spoustu změn delší dobu jen v commitech svého repozitáře (u rozsáhlejších změn k tomu dochází), musím pravidelně rebasovat (nebo mergovat, já dávám přednost rebasu) změny kolegů a když je konflikt, musím si jej pořešit u sebe a dát jim vědět, aby v té části případně počkali, až to dodělám a pushnu do centrálního repa. Jinak budu muset jejich další commity opět opravovat. Jo, po čase začnou vrčet, abych to dodělal a pushnul, že už je zdržuju. A mají pravdu. Ale to je IMO úplně normální součást vývoje, zámky by tomu nijak nepomohly, jen by vše zasekaly.

[Filip Jirsák]

Pokud to bude nějaký BLOB (u kterého to má smysl takhle dělat), editor ho na začátku otevře pro čtení a načte do paměti. Pak s tím bude ten editor v paměti pracovat a teprve na konci, když to uživatel bude chtít uložit, otevře ten soubor pro zápis a zapíše ho. Notifikovat při zápisu by tedy bylo zbytečné, to už jsou změny provedené. Musel bys notifikovat při čtení, přičemž ten soubor může být čten z mnoha různých důvodů, nejenom proto, že bude následně editován.

[xkucf03]

BLOBy ve verzovacím systému běžně nemám a když už, tak jsou to třeba obrázky, které se jednou vytvoří a pak se skoro nemění, nebo jiná multimédia, ale typicky je to věc, kterou spravuje jen jeden člověk z týmu a nikdo jiný mu do toho neleze, takže konflikty nehrozí.

Jde spíš o zdrojáky – např. něco přejmenuješ, přesuneš, přidáš podmínku nebo odchytávání výjimky (a tím odsadíš blok a změníš všechny řádky v něm) nebo přidáš parametr do metody. Kolikrát by stačilo chvíli počkat (dělat něco jiného), než pak ztrácet čas řešením konfliktů.

[Filip Jirsák]

Jak ztrácet čas řešením konfliktů? Nic z toho, co jsi popsal, nezpůsobuje konflikt. Navíc zamykání souborů vůbec nefunguje na feature branche, které se následně mergují do hlavní větve. Pokud vývojáři pracují s distribuovaným VCS a na zdrojových souborech by potřebovali zamykání, dělají něco nejspíš hodně divně - a vůbec nemá smysl, aby distribuovaný VCS používali, protože jim nic nepřinese.

[xkucf03]

Jak ztrácet čas řešením konfliktů?

Čas a nervy – někteří to dost špatně snášejí.

Já to řeším většinou tak, že dělám co nejčastěji merge/rebase a push.

Nic z toho, co jsi popsal, nezpůsobuje konflikt.

Konflikt způsobuje všechno – stačí změna na stejném řádku a Git (nebo jiný nástroj pracující na úrovni textu) je z toho v háji. To by bylo potřeba, aby nástroj pro diff/merge rozuměl danému jazyku – to by pak mohl např. provést refaktoring i v kódu, který v tu dobu nebyl k dispozici (byl ještě na počítači jiného vývojáře).

Navíc zamykání souborů vůbec nefunguje na feature branche, které se následně mergují do hlavní větve.

Ten nástroj by měl vědět, z které větve do které budou změny putovat, co je z čeho odvozené a upozornit i vývojáře pracující na jiných větvích.

Pokud vývojáři pracují s distribuovaným VCS a na zdrojových souborech by potřebovali zamykání

Nejde o striktní zamykání – jde o automatizované sdílení informace o tom, kdo na čem dělá. Jak s tou informací ostatní naloží, to už je na nich. Můžeš ji ignorovat a předběhnout ostatní, můžeš udělat commit u sebe, počkat si na změny od kolegy a pak si udělat merge/rebase, nebo se konfliktním místům vyhnout a dělat chvíli něco jiného. Záleží na situaci, ale tak jako tak mi přijde fajn tuhle informaci mít. Je to asi jako když se můžeš podívat do bugzilly, na čem ostatní dělají – jen tohle by bylo na úrovni souborů.

dělají něco nejspíš hodně divně - a vůbec nemá smysl, aby distribuovaný VCS používali, protože jim nic nepřinese.

Vždycky něco přinese: rychlejší práci s historií, možnost práce offline, rychlejší přepínání větví, systematičtější větve a štítky (nejsou to jen nějak pojmenované adresáře), možnost si něco vyzkoušet u sebe, aniž bych zprasil centrální úložiště, snadné inkrementální zálohování, větší flexibilitu, možnost mít např. víc úložišť a přetahovat mezi nimi změny po revizi atd.

[Filip Jirsák]

Konflikt způsobuje všechno – stačí změna na stejném řádku

No právě. Jak k tomu dojde, že dva programátoři mění nezávisle na sobě stejný řádek?

Ten nástroj by měl vědět, z které větve do které budou změny putovat

Takže nezbytným hardwarovým doplňkem bude křišťálová koule?

Nejde o striktní zamykání – jde o automatizované sdílení informace o tom, kdo na čem dělá.

Podle mne tahle informace nemá být sdílená ex-post, ale předem, při rozdělování úkolů. Pokud dělají dva lidé na stejné věci, jsou konflikty vzniklé při mergování ten nejmenší problém. Mnohem víc problémů vznikne v kódu, ve kterém nebudou konflikty na úrovni zdrojových kódů, ale na úrovni významu.

Je to asi jako když se můžeš podívat do bugzilly, na čem ostatní dělají – jen tohle by bylo na úrovni souborů.

Rozdíl je v tom, že na úrovni bugzilly to význam má, na úrovni souborů ne. Protože to, co vývojář dělá, je vyjádřené právě v té bugzille – změna souborů je jenom nástroj, jak to udělat.

Vždycky něco přinese: rychlejší práci s historií, možnost práce offline, rychlejší přepínání větví, systematičtější větve a štítky (nejsou to jen nějak pojmenované adresáře), možnost si něco vyzkoušet u sebe, aniž bych zprasil centrální úložiště, snadné inkrementální zálohování, větší flexibilitu, možnost mít např. víc úložišť a přetahovat mezi nimi změny po revizi atd.

Přičemž shodou okolností všechny tyhle přínosy jsou nekompatibilní s centrálním zamykáním (ať už pesimistickým nebo optimistickým).

Nezdá se mi, že by třeba vývojáře linuxového jádra trápilo mergovací peklo. Ostatně, Git si napsal Linux sám právě pro vývoj jádra, takže kdyby to mergování byl problém, nejspíš by mergování napsal tak, aby kódu rozumělo. A to je přitom jádro dost kompaktní projekt, různé enterprise projekty mají podstatně volnější vazby, takže pravděpodobnost, že se vývojáři potkají na stejném kódu, je mnohem menší.

[dustin]

např. něco přejmenuješ, přesuneš, přidáš podmínku nebo odchytávání výjimky (a tím odsadíš blok a změníš všechny řádky v něm) nebo přidáš parametr do metody.

Tady právě hodně pomáhá rozpadat metody na minimální kousky kódu, které mají jen pár řádek. Málokdy se oba trefí do stejné metody... Navíc se tím kód výrazně zdokumentuje - výstižně pojmenované krátké metody (téměř nikdy nestačí jednoslovně) jsou lepší než komentáře.

Git má rád bílý prostor. Když se může něčeho chytit v blízkém okolí změny, dochází k minimu konfliktů.

[Kit]

Metody běžně pojmenovávám jednoslovně a přesto výstižně.

[dustin]

Jojo, to už jsem párkár viděl. A k tomu názor, že přejmenování není potřeba.

[Kit]

Názvy privátních proměnných a atributů si mohu dělat, kdy se mi zlíbí. Při změně názvů v rozhraní však musím brát na zřetel, že to může mít vliv na všechny třídy, které dané rozhraní implementují a také na všechna volání i z ostatních projektů. Proto si takové změny důkladně rozmyslím.

[dustin]

Opět - selský rozum. Přejmenovávám, jen pokud si to mohu dovolit, to je snad jasné. Pokud ano, pak je pro mě prioritou kvalitní vysvětlující název a ne stručnost názvu či minimalizace provedených změn.

[Kit]

Dělám snad něco jiného? Základem je kvalitní vysvětlující název, který nemá vazbu na vnitřní strukturu třídy, ale na její vnější chování.

[AraxoN]

Ak sú vývojári na jednom mieste dá sa použiť na zamykanie fyzický token. Nejaký unikátny ale inak zbytočný predmet v kancelárii, napríklad magnetka z dovolenky. Kto ju má u seba, ten má exkluzívny zámok a môže editovať. Kto ju nemá a potrebuje, tak sa začne po nej zháňať, čo ho skôr či neskôr dovedie k danému kolegovi a nejak sa dohodnú. Rieši to problém lepšie než zamykanie cez CVS/SVN, ktoré je príliš "definitívne". Napríklad nám sa stalo kedysi dávno u inej firmy, ešte za čias CVS, že kolega zamkol súbor, spravil svoj commit a potom odišiel na dovolenku. Len zabudol odomknúť, takže sme s tým nemohli ďalej robiť. Tuším že admin nakoniec obnovil celý repozitár zo zálohy ešte pred zamknutím a zmeny sa museli ešte raz preniesť ručne. Zabili sme s tým celý deň a všetci boli z toho dosť nervní.

[Michal Kubeček]

Všem, kdo vymýšlejí podobné důmyslné systémy, bych doporučoval zamyslet se nad tím, jak by asi něco takového fungovalo u projektů rozsahu linuxového jádra, LibreOffice nebo Firefoxu.

Ano, existují mimořádné situace, kdy má smysl říct: "Hele, kluci, chystám se tuhle část od základu překopat, počkejte s neurgentními změnami do příštího týdne." Ale to jsou dost řídké výjimky, které lze řešit třeba přes mailing list. V drtivé většině případů standardní git based workflow škáluje směrem dolů velmi dobře i na malé projekty. Naopak, workflow založený na úzkostlivém předcházení potenciálním konfliktům (navíc s pochybnou granularitou po souborech) přestane směrem nahoru škálovat velmi rychle.

[xkucf03]

Ono je otázka, co je příčina a co následek. Pokud to velikost týmu a použité nástroje nedovolují, tak si zvykneš, že se moc nerefaktoruje, radši obětuješ změnu k lepšímu ve prospěch stability a toho, že ostatním nezpůsobíš potíže a nebudou ti nadávat (což riskuješ, když nevíš, kdo na čem zrovna pracuje). Časem ti to přijde normální, zvykneš si a budeš mít pocit, že ti nástroj vyhovuje.

Když ale budeš pracovat v prostředí, kde je zvykem hodně refaktorovat (např. Java, což souvisí mj. s dostupností spolehlivých nástrojů pro refaktoring oproti jiným jazykům) a navíc budeš dělat na novém produktu, kde je potřeba refaktoringu vyšší, tak ti to bude chybět – resp. budeš obcházet kolegy a říkat jim, ať přeruší práci, že jdeš něco předělat (protože se ti nebude chtít poslouchat jejich nadávání, až budou muset dělat merge).

Informace, které bych uvítal:

• že přibyla nová verze ve vzdáleném úložišti (to se dá řešit e-mailem), jinak totiž někdy dochází k úplně zbytečným konfliktům, když si člověk zapomene stáhnout aktuální verzi než začne pracovat
• kdo na kterých souborech pracuje (to se dneska řeší leda obcházením kolegů nebo ručně psanými e-maily)

[dustin]

Tak maily s novými commity zasílanými z centrálního repo jsou samozřejmost - napojené na push hook. Z lokálních repo bych je nechtěl, to se pořád mění.

[Matlák]

Java, což souvisí mj. s dostupností spolehlivých nástrojů pro refaktoring oproti jiným jazykům

Jo, klik-klik, přejmenuj všechny třídy, klik. Změněno 1264 souborů. Lidem co používají IDE a nechají si od něj doporučovat postupy vývoje bych urazil ruce. Nehledě na to že takovéhle automatizované "refaktoringy" těžko podepřeš nějakým notifikačním systémem.

když si člověk zapomene stáhnout aktuální verzi

Pravda. A přitom prostě stačí si aktuální verzi stáhnout pokaždé když začneš pracovat. A trochu koukat kolem sebe - na čem se pracuje, co se začíná dělat a bude dělat (bugzilla/jira a podobné) a co kdo zrovna commitnul (třeba přes Gitlab). Notifikace "Uživatel Franta právě otevřel soubor IsEvenlyDivisibleStrategy.java" je nakonec rušivá a celkem ku prdu.

[Matlák]

BTW nad merge requesty feature větví s tunami změněných souborů co nemají se zadáním nic společného pěním vždycky. Pokud je potřeba něco refaktorovat, mělo by se to IMHO rozhodnout dřív, vytvořit nezávislá větev, zrefaktorovat, merge. A ne že až stavebník hrábne lopatou do země, tak zjistí že potřebuje sbíječku. A nebo trhaviny.

[Michal Kubeček]

Někomu se to možná nebude líbit, ale přístup "máme efektivní nástroje pro refactoring, tak budeme refactorovat, až se z nás bude kouřit" mi přijde trochu jako "uložit a přeložit je rychlé, tak budu programovat metodou pokus-omyl". Vývojář by neměl dělat věci proto, že na to má pohodlné nástroje, ale proto, že je to v daném okamžiku nejlepší řešení.

Osobně si myslím, že refactoring by měl být vnímán jako krajní možnost a spíš jako určitá forma kapitulace. Obvykle to znamená, že něco bylo navrženo tak špatně, že nic jiného nezbývá a že i všichni budoucí maintaineři a vývojáři, kteří nás za něj budou proklínat, až budou hledat, kde se vzal nějaký kus kódu a proč, jsou menší zlo než nechat ten kód jak je. Ano, čas od času se to stane, ale rozhodně není refactoring něco, co by se mělo dělat s lehkou hlavou a tím, že je to přece jednoduché a máme na to spolehlivé nástroje.

[dustin]

Jestliže potřebuji na stávajícím kódu (třídě) udělat něco nového/opravit/rozšířit, tak jej nejdříve upravím tak, aby se mi líbil. Proměnné a metody přejmenuju, aby dávaly smysl, metody rozpadnu na kratší. Samozřejmě koukám, kde všude se přejmenování projeví, jako u všeho i zde je potřeba používat selský rozum. Někdy je změn více, někdy méně, někdy žádná. Žádnou kapitulaci v tom nevidím, prostě normální údržba kódu, součástí každodenní práce na dlouhodobě provozovaném živém kódu. Přece nebudu pořád dokola zakopávat o stejný klacek, když jej mohu z cesty odhodit. Pak to commitnu s příslušným popisem a začnu dělat na funkčních změnách. Zda se to nazývá či nenazývá refaktoringem je mi jedno, jde o výsledek, ne o slovíčkaření. Přesně to samé vyžaduji od svých kolegů, je to jako mít aspoň trochu uklizeno na pracovním stole.

[Michal Kubeček]

Asi by vám prospělo, kdybyste nějaký čas (aspoň tak rok nebo dva) strávil tím, že budete místo přidávání nových featur maintainovat existující kód, který psal někdo jiný, a debugovat a opravovat chyby v něm. Pak byste se snad na to zdánlivě nezbytné neustálé "uklízení si pracovního stolu" začal dívat trochu jinak.

[dustin]

Přesně to dělám už spoustu let, každý den. Ten kód je dost rozsáhlý a pořád narážím na legacy třídy. A o to víc je mi jasné, že k čištění je potřeba využít každé příležitosti a nerezignovat nad tím. Jinak se kód stává zcela neudržitelným a nerozšiřitelným. Mrtvým, s nulovou hodnotou do budoucna. Což je bohužel asi standard většiny projektů, kde se na to neklade důraz (což jak se zdá je dost časté).

[Michal Kubeček]

Obávám se, že každý mluvíme o něčem jiném. Kdybyste dělal to, co jsem měl na mysli, musel byste nezbytně narážet na to, jak takové hromadné úklidové změny komplikují jakékoli hledání v historii.

[dustin]

Mluvím oba o tom samém. Historii (popisy, diffy vůči libovolným verzím) vidím v IDE v historii commitů (včetně návazností při přejmenování, od toho git umí git mv), v blame výstupu, atd. Pro mě má daleko vyšší hodnotu aktuální kód, se kterým pracuju. Když se potřebuju podívat na průběh změn (obvykle jde hlavně o popisy commitu), dohledám si to, obvykle na pár kliknutí. Kvůli snadnému hledání v historii nezakonzervuji stávající kód, abych o něj pořád zakopával.

[Michal Kubeček]

v blame výstupu, atd. Pro mě má daleko vyšší hodnotu aktuální kód, se kterým pracuju. Když se potřebuju podívat na průběh změn (obvykle jde hlavně o popisy commitu), dohledám si to, obvykle na pár kliknutí

A to je právě to, co v kódu vyvíjeném podle vašich představ moc dobře nefunguje. Každý git blame budete muset zopakovat pětkrát, protože první čtyři pokusy vám ukážou akorát commity typu "přejmenovat CoolClass na VeryCoolClass" a "prohodit pořadí parametrů CoolHelper(), protože takhle je to logičtější". A když se konečně doberete ke commitu, který skutečně zavedl to, co vás zajímá, zjistíte, že mu vůbec nerozumíte, protože třídy a metody, které se tam používají, už v současném kódu dávno neexistují, takže nejdřív budete muset zjistit, jak tehdy fungovaly.

Linuxové jádro je naštěstí přes usilovnou snahu některých "uklízečů" poměrně konzervativní a podobným samoúčelným změnám se snaží vyhýbat. Ale i tak je často o nervy něco hledat v pár let staré historii. Jak by to vypadalo, kdyby se refactoring podle momentální nálady prováděl při každé příležitosti, jak to propagujete vy, to si raději ani nesnažím představit.

A to ani nemluvím o tom, co takové dobře míněné změny způsobí v okamžiku, kdy máte nějakou backportovat do starší verze. V lepším případě to bude jen hodně práce nevíc. V tom horším začnete narážet na těžko předvídatelné chyby.

[dustin]

A proto jsem mluvil o selském rozumu. Pokud na kódu dělají tisíce lidí jako na kernelu, pokud potřebuji backporty do starší verze, pokud mám v kódu featury, které nemám šanci ani náhodou otestovat (drivery), pak logicky použiji úplně jiný přístup ke změnám, než když relativně malý tým vyvíjí vlastní produkt, který se provozuje jen v poslední stabilní verzi, ale který má cca deset tisíc tříd a přicházejí na něj každý týden nové/změněné požadavky, jak se vyvíjí trh/byznys/požadavky klientů.

Proto také říkám "pro mě, pro nás". Refaktoring pro nás není kapitulace, ale nezbytná cesta vpřed, jak udržet projekt pod kontrolou a rozvíjitelný. Jo, máme výhodu rozvázaných rukou, o tom žádná. Ale tu jsme si technickým řešením našeho produktu/způsobu vývoje dobrovolně vybrali a záměrně se jí držíme.

[xkucf03]

Ak sú vývojári na jednom mieste dá sa použiť na zamykanie fyzický token. Nejaký unikátny ale inak zbytočný predmet v kancelárii, napríklad magnetka z dovolenky. Kto ju má u seba, ten má exkluzívny zámok a môže editovať

To bys musel mít magnetku pro každý soubor nebo alespoň modul. To je dost malá granularita.

Tuším že admin nakoniec obnovil celý repozitár zo zálohy ešte pred zamknutím a zmeny sa museli ešte raz preniesť ručne. Zabili sme s tým celý deň a všetci boli z toho dosť nervní.

Administrátor se snad může přihlásit jeho jménem (např. dočasně změnit heslo) a zámek zrušit, ne?

Navíc já tu nenavrhoval zámky, ale jen systém upozornění, který by ti řekl, kdo na čem pracuje, ale bylo by na tobě, jestli se tím budeš řídit.

[Michal Kubeček]

Pořád v tom moc nevidím moc smyslu.

• Musela by se evidovat informace nejen o tom, jaký soubor měním, ale také v jaké větvi. Nemá totiž smysl, aby kvůli drobné opravě v nějaké stable větvi systém otravoval všechny, kdo pracují se stejným souborem v master.
• Ve skutečnosti by ale spíš bylo potřeba vědět, do jaké větve ve sdíleném repozitáři je změna (finálně) určena - a takovou informaci bych musel nějak předem poskytnout. (Třeba i implicitně - např. že by lokální větve musely být pojmenované jednotným způsobem, z něhož jde algoritmicky určit cílová větev.)
• Stejná změna může být ovšem určena pro více cílových větví.
• Změny v jednom souboru spolu vůbec kolidovat nemusejí - a naopak, mohou spolu kolidovat změny v různých souborech.
• Od doby CVS svět trochu pokročil, takže commit by měl obsahovat nějakou logicky ucelenou změnu, která ale velmi často zasahuje do několika různých souborů.
• Změna, kterou provádím dnes v editoru, může skončit ve sdíleném repozitáři třeba až za několik měsíců - a nebo taky vůbec.
• Spousta (nejspíš i většina) změn, které provádím na své lokální kopii, se ve skutečnosti nikdy nedočká toho, že by byly pushnuty. Nemalá část se nedočká ani commitu.
• Použitím inotify se sice řeší problém, že řada změn vznikne bez editoru (např. čistý cherry pick), ale vzniká jiný: bylo by potřeba ošetřit operace, které změní soubory, aniž by se jednalo o "změnu" (např. checkout).

Celé mi to tak trochu připadá, jako by někdo nepochopil, proč vlastně vznikly DVCS a co přinášejí a snažil se git používat jako trochu modernější CVS.

[Filip Jirsák]

Navíc i kdybych měl ten soubor zamčený v jedné větvi, budu ten domnělý konflikt stejně řešit při slučování každé větve, takže mi ten zámek vůbec nepomohl. Aby ten zámek pomohl, musel by se daný soubor nejprve sesynchronizovat ve všech větvích (což efektivně znamená nepoužívat žádné větve), pak teprve zamknout. Po změně by ten souboru musel být v každé větvi zamčený tak dlouho, dokud se do něj uvedená změna nepromítne.

[Josef Kufner]

Jak už napsali jiní, Git tohle sám o sobě nepotřebuje. Někdy se to ale hodí. Nedávno s touhle funkcí přišel Gitlab v Enterprice edici – viz verze 8.9.