A tag-eknek van még egy(-két) huncutsága, amelyekből a másodikra most nem emlékszem pontosan, de arra emlékszem, hogy korábban (többször is) belebotlottam.
Az első huncutság az, hogy a tag-ek nem repo- (= nem remote-) specifikusak, mint a branch-ek. Ha van két remote-ot egy local clone-ban, akkor mindegyik remote-nak lehet azonos B nevű branch-e, amelyek tudnak tök máshova mutatni. A tag-ekre ez -- tudtommal -- nem igaz; ott egyetlen közös névtér van. Ezért is szoktam nem-kanonikus remote-okat mindig a "--no-tags" opcióval klónozni, illetve (a "git remote add -f" paranccsal) létező helyi klónhoz hozzáadni -- nem akarom, hogy "beszennyezzék" a kanonikus repo tag-névterét. (Megfigyelhető, hogy azok a kanonikus repo-k / remote-ok, amelyeknél tervezett, hogy a fejlesztők egyazon helyi klón-on belül többet is használjanak belőlük, ügyelnek arra, hogy valamilyen tag-elnevezési konvencióval az ütközéseket elkerüljék. Pl. mainline és stable fák között a "git cherry-pick -x" nagyon hasznos, és mindegyik ilyen fa használ tag-eket; nekik muszáj figyelni arra, hogy a tag-ek ne ütközzenek.)
A második huncutság valahol a push vagy a pull környékén volt. Úgy rémlik, hogy klónoztam egy repo-t, amiben voltak olyan tag-ek, amelyek nem voltak egyúttal valamely branch-en is. A git clone csak a branch-eket hozta le (mint symbolic ref-eket), illetve (természetesen) a gráf mindazon részét, amely ezekből a branch-ekből elérhető volt; a tag-eket viszont (és a gráf azon részét, amely csak a tag-ekből volt elérhető) nem töltötte le. És ha jól emlékszem, ez nem a "--no-tags" következménye volt... de már homályos.