Názory k článku Pohodlná správa zásuvných modulů v Gitu

To obrozenectví už se vážně vymyká kontrole. S gitem pracuji prakticky denně, ale po přečtení nadpisu jsem stejně marně přemýšlel, čemu by se mohlo v obrozenčině říkat zásuvné moduly. Říkal jsem si, že snad jedině submodules - ale proč "zásuvné"? Správná odpověď mne vůbec nenapadla... Korunu tomu ovšem nasadil závěr: tvorba vlastních zásuvných modulů pro pluginy. :-)

Námět k zamyšlení: k čemu je v odborném textu dobré vynalézat termín, kterému bez dodatečného vysvětlení neporozumí ani zkušený uživatel?

Výraz „zásuvný modul“ se jako překlad anglického "plug-in" používá mezi uživateli v IT zcela běžně už od 90. let minulého století. Já jsem se s ním poprvé setkal v lokalizaci Adobe Photoshop 2.5.

To že programátoři nepoužívají lokalizace a všechno mají v angličtině je problém jejich vnímání světa.

Výraz „zásuvný modul“ se jako překlad anglického "plug-in" používá mezi uživateli v IT zcela běžně už od 90. let minulého století.

...a to je právě součást problému. Možná vám totiž uniklo, že v tomto článku se výraz zásuvný modul používá jako překlad anglického hook a v citované poslední větě je navíc použit v kombinaci právě s oním (nepřeloženým) slovem plugin, čímž je zmatení dokonáno.

Ja to vidim takhle:

1. Existuje nekdo, kdo si tento clanek precte a nebude rozumet pojmu plug-in? Asi tezko.

2. Existuje nekdo, kdo chce pouzivat github hooks a vyhne se pri samotnem pouziti vyrazu “hook”? Asi tezko.

Tak proc si to komplikovat? Muzeme to psat hezky anglicky a vyhneme se vsem nejasnostem.

S odstupem pár dnů musím uznat, že ty překlady nebyly úplně šťastně zvolené. Souhlasím, že nemá smysl si to komplikovat. Díky za komentář.

Přesně tak. Už si přesně nepamatuji jak tu hooky překládají? Háčky?
Toto mě na Rootu vadí. Za každou cenu se tu snaží překládat pojmy, které se prostě v běžném životě nepřekládají a akorát to způsobuje nedorozumění. Už jen kvůli snazšímu dohledání v manuálu nebo na internetu je lepší pojmy používat nepřeložené. Že se tu někomu nezdá věta "tvorba vlastních hooků pro pluginy" a radši napíše "tvorba vlastních zásuvných modulů pro pluginy"... to už je špatný fór.

Překlad "háčky" jsem vídával v Jaderných novinkách. Sice to zní trochu úsměvně, ale logicky to dává smysl a hlavně to má výhodu, že to odpovídá i tupým překladem, takže pro toho, kdo je zvyklý na anglický výraz, je snadné pochopit, co se tím myslí.

Už na to byly i vtípky. Ve firefoxu vyletěl messagebox "Došlo k selhání zásuvného modulu." a k tomu ilustrační obrázek, který sem radši nebudu přikládat, aby mi root nebloknul účet :-)

Co mi u běžného použití pre-commit hooku vadí je že to pracuje nad soubory jak jsou v adresáři, ne jak jsou stagované. Tohle ten tool řeší , případně je na to nějaký standardní postup? Z textu ani dokumentace není jasné jestli --all-files se týká seznamu souborů nebo jejich obsahu.

Zatím dělám v precommitu něco na způsob git clone/worktree ... git diff --cached | patch , ale čekal bych něco jednoduššího.

Nástroj pre-commit defaultně pracuje nad soubory ve stage. Přepínač --all-files řekne "pracuj nad všemi soubory v repozitáři". Jestli to chápu správně a potřebujete, aby pracoval jen např. se změněnými řádky, tak se mi z dokumentace nezdá, že by tohle nástroj pre-commit uměl.

Můžete zkusit třeba nějakou z alternativ zmíněných v úvodu (husky, overcommit nebo lefthook), třeba to budou umět. Nebo zkusit štěstí na Awesome Git Hooks: https://github.com/aitemr/awesome-git-hooks.

Díky, podívám se,

Jen pro vysvětlení - jde mi o to, aby se kontrola prováděla nad verzí repozitáře tak jak bude po commitu před kterým se pre-commit dělá. To v zásadě znamená bez změn které jsou ve work tree ale nejsou stageované (a tedy i bez souborů které nejsou pod gitem). Které řádky a soubory se mění příslušným commitem mne při tom nezajímá.