Git explorer integratie zoals TortoiseHg?

[Fuzzillogic]

Ik werk al jaren naar tevredenheid met Mercurial als SCM. Maarja, tegenwoordig is Git helemaal hip. De systemen delen veel concepten. En werkelijk, op basis van het coresysteem kan ik geen winnaar aanwijzen.

Maar... ik werk toch vooral in Windows en het is toch ook wel prettig om fatsoenlijke explorer-integratie met icoontjes te hebben, evenals goede Windows tooling. De GUI van mSysGit, de default voor Windows, is een zooitje en maakt me verdrietig. TortoiseGit is dan al een stuk beter, overlay icoontjes die het meestal goed doen; f5 is soms een must om ze te tot updaten te bewegen. (Een "feature" die ik nog van TortoiseSVN ken...)

De standaard-tool voor Mercurial, TortoiseHg, is dan toch echt een duidelijke verbetering: icoontjes zijn altijd up-to-date en de hele toolset is vanuit één overzichtelijke tool te beheren.

Aangezien de meeste devvers toch nog echt in Windows developen en Git ook daar zo populair is vraag ik me af wat ik mis. Tools genoeg, maar zijn voor zover ik zie stand-alone en/of commercieel. Die explorer-integratie is toch wel bijzonder prettig. Is er betere integratie te vinden dan wat TortoiseGit biedt? Zo niet, dan blijf ik voor nu lekker bij Mercurial.

[RobertMe]

Je hebt ook nog Git Extensions. Deze heeft AFAIK ook shell/explorer integration (naast integratie met Visual Studio, mocht je dat gebruiken). Geen idee hoe goed die werkt, zelf werk ik meestal gewoon met "Git Bash" (van MSysGit dus).

[YopY]

Ben ik gek als ik "commandline FTW" zeg? Ik erger me aan GUIs voor Git, ze verstoppen informatie en duidelijkheid die ik met een git status (of git s, alias voor git status --short) wel zie. GUIs om het log te bekijken zijn dan nog wel handiger dan de commandline vind ik, maar voor het gewone werk - pull, merge, rebase, push, add, commit, etc - geef mij maar de commandline. Daar moet ik natuurlijk wel bij zeggen dat de commandlines voor Windows best wel deprimerend zijn, Bash emulators die voor geen meter performen en soms gewoon volledig de kluts kwijt raken. Maar daar is mee te leven.

[Fuzzillogic]

Git Extensions had ik nog niet getest maar ik miste de overlay-icoontjes van Tortoise* in de screenshots. En dat vermoeden klopt: die zijn er niet. Ik vind dat juist wel zo handig. De tool zelf ziet er wel al een stuk verzorgder en helderder uit. Maarja, om nu TortoiseGit enkel te draaien voor de (soms wat brakke) overlay-icoontjes?...

En nee je bent niet gek als je zegt commandline FTW (overigens, THG biedt directe commandlinetoegang vanuit de workbench ) en ik ben ook niet vies van de CLI. Maar zeker als je in een team werkt is snel overzicht van de changes inclusief diff erg handig.

Overigens, een goede IDE als Netbeans biedt eigenlijk ook al veel features voor Git en Mercurial, inclusief visuele onderscheiding van nieuwe en gewijzigde files. Toch vind ik explorer-integratie fijn.

[eamelink]

Ik gebruik geen Windows en voor OS X zijn er prima GUI's voor git, maar ik prefereer toch ook de commandline. Zeker met iets leuks als git situational awareness werkt dat wat mij betreft een stuk beter dan de meeste GUI's. Ik open eigenlijk alleen een GUI als het helemaal fubar is en ik even naar de trees wil kijken

[YopY]

Dus goeie explorer-integratie in de vorm van icoontjes is belangrijk? Want anders zou ik Github for Windows nog naar voren schuiven, UI-technisch gezien een mooie / overzichtelijke applicatie (met git bash als commandline fallback; het is niet bepaald feature-complete). Github gebruik niet verplicht.

[Fuzzillogic]

Hmm dat ziet er wel heel hipster windows 8 uit... En de tool zelf is niet eens open source? Dat is gezien de maker en het doel toch op zijn minst opmerkelijk te noemen. Github-gebruik wordt ook wel flink gepromoot. Het kan mij niet overtuigen.

Explorer-integratie met overlayicoontjes maken het werk handig voor als je buiten de IDE dingen moet doen. Je ziet direct dat er nog uncommitted bestanden zijn en welke dat zijn. Zeker als je nog iets met die bestanden aan het doen bent scheelt het ook weer zoeken.

Bedankt voor het meedenken, maar ik houd het maar bij Mercurial. Anders dan de populariteit van Git heeft Git voor mij nu geen zichtbare voordelen. Dat heeft Mercurial wel: TortoiseHg. Daarnaast is Mercurial meer vanuit een cross-platform idee opgezet is dan Git. Dat merk je ook op de CLI: zet hg.exe in je pad en je kunt het ook gewoon in de command prompt gebruiken zonder verdere poespas. Op een Windows VPS draai ik cygwin voor ssh icm Mercurial, dat behoefde ook geen verdere aanpassingen.

[Sebazzz]

Wat is er mis met TortoiseGit? Werkt prima hier

[Fuzzillogic]

Edit een file en save het. Icoontje wordt rood. Doe ctrl+z in de editor zodat de oorspronkelijke situatie weer hersteld wordt en save het weer. Icoontje blijft rood. Pas na f5 weer groen. Kleine ergernis, maar toch, je kunt er blijkbaar niet op vertrouwen. Daarnaast is het, net als met TortoiseSVN, een bonte verzameling van windowtjes en menuitems, waar de workbench van TortoiseHg overzichtelijke alles in één is.

Maar TortoiseGit is zeker geen slecht product, en de prijs/kwaliteitverhouding is een heel stuk beter dan van TFS Het is het verschil tussen TGit en THg is een 8+ vs 9-, te weinig om over te stappen. Ook andere Windows Git tools zijn gewoon goed, maar halen het net niet bij THg.

Overigens zegt het niks over de kwaliteit van Git en Hg zelf, de plussen en minnen zijn daar helemaal tegen elkaar weg te strepen imo.

Ik ging het weekend in om een reden te vinden naar Git over te stappen. Jaren geleden heeft m'n werkgever voor Mercurial gekozen vanwege de betere Windows tooling en ik ben simpelweg blijven hangen; het beviel me wel. En ook al ben ik vaak tegendraads en eigenwijs, "go with the flow" is soms toch wel zo makkelijk. Dat zou voldoende reden zijn geweest, maar ik kom tot de conclusie dat de Hg GUI tooling toch nog steeds een tikje beter is. Bij elkaar opgeteld: geen reden tot overstap, niet vanuit Git naar Hg, en niet vanuit Hg naar Git. Ga je voor het eerst met een (D)VCS werken en ook nog in Windows, dan is Mercurial denk ik makkelijker.

[curry684]

Herkenbaar verhaal, ik heb vorige week uitgebreid onderzocht of het voor ons bedrijf interessant is om over te stappen van SVN naar Git. Na een paar avonden drama tot en met met de servertools, die allemaal eigenlijk nog te onvolwassen zijn om serieus genomen te worden in een enterprise omgeving (to name one: voor zover LDAP/AD integratie mogelijk is werkt het vervolgens in de praktijk nauwelijks tot niet) bleken de clientside tools eigenlijk net zo brak te zijn omdat ze allemaal achter de schermen terugvallen op systemcalls naar de commandline tools.

Mijn eindconclusie was ook dat Git vast een prachtig systeem is, maar nog minimaal een jaar of 2~3 nodig heeft voor het de volwassenheid heeft dat je het ook aan een groep developers durft te geven die niet dagelijks in een Linux-shell zitten te rammen. Dat gecombineerd met dat wij door ons ontwikkelmodel eigenlijk nul profijt hebben met het distributed karakter van DVCS maakt dat wij voorlopig nog gezellig ende tevreden op SVN blijven zitten.

[__fred__]

Helemaal waar, de goede gui heb ik ook nog niet helemaal gevonden... maar ik heb een redelijk compromis:

- Github windows client gebruik ik voor de dagelijkse dingen. Mooie windows 8 interface.
- Git Gui om tree's te bekijken etc, cherry picking, dat soort dingen
- Git shell voor het echte handwerk
- git source control provider plugin voor visual studio integratie.

Deze combo werkt heel aardig en de snelheid en overige mogelijkheden van git maken voor mij dat ik nooit meer terug wil naar svn, maar dat is persoonlijk natuurlijk.

[djc]

curry684 schreef op dinsdag 09 oktober 2012 @ 01:04:
Mijn eindconclusie was ook dat Git vast een prachtig systeem is, maar nog minimaal een jaar of 2~3 nodig heeft voor het de volwassenheid heeft dat je het ook aan een groep developers durft te geven die niet dagelijks in een Linux-shell zitten te rammen. Dat gecombineerd met dat wij door ons ontwikkelmodel eigenlijk nul profijt hebben met het distributed karakter van DVCS maakt dat wij voorlopig nog gezellig ende tevreden op SVN blijven zitten.

Misschien toch ook eens naar Mercurial kijken?

[curry684]

djc schreef op dinsdag 09 oktober 2012 @ 10:51:
[...]
Misschien toch ook eens naar Mercurial kijken?

Even de irritante manager uithangen "Welke voordelen heeft het boven SVN dat het de investering van tijd en moeite waard zou maken?"

[steffex]

met svn2git kun je supersnel repos omzetten naar Git, inclusief history. Dus dat hoeft geen tijd te kosten.

of je gebruikt gewoon svn support in Git

[curry684]

steffex schreef op dinsdag 09 oktober 2012 @ 11:04:
met svn2git kun je supersnel repos omzetten naar Git, inclusief history. Dus dat hoeft geen tijd te kosten.

of je gebruikt gewoon svn support in Git

Ja, en dan ben je dus aan het overstappen puur om het overstappen, met alle conversierisico's, nieuwe tools uitrollen, mensen inleren in nieuwe tools, gezeik met dingen die 'anders werken'. Als de conversie 1 uur kost en het inwerken in nieuwe tools een week aan productiviteit ben ik alsnog een week kwijt.

Again: welke redenen heb ik als manager om die risico's te nemen en die kosten te investeren

[compufreak88]

Betere branching (en dus ook workflow) support. Meeste commando's die lokaal worden uitgevoerd in plaats van over het netwerk moeten.

Maar inderdaad. Dingen als LDAP support is er eigenlijk nauwelijks. git heeft vanwege zijn decentrale natuur geen ACL ingebouwd.

Daarom zijn er dingen als gitolite bedacht, die op ssh niveau ACL toevoegd (en ook op repo niveau).

[curry684]

compufreak88 schreef op dinsdag 09 oktober 2012 @ 11:56:
Betere branching (en dus ook workflow) support.

Granted, dat was voor mij de hoofdreden dat ik ernaar keek. Maar gezien bij ons bedrijf (internetbureau) in de meeste gevallen de relatie tussen ontwikkelaar en project 1 op 1 is is dit geen sterk argument voor ons.

Meeste commando's die lokaal worden uitgevoerd in plaats van over het netwerk moeten.

Wat mensen vaak makkelijk over het hoofd zien: dat zie ik dus net zo sterk als nadeel als als voordeel, misschien nog wel sterker. Ik wil helemaal niet dat een ontwikkelaar een week offline werkt, want dan is ie een week werk kwijt als z'n harddisk het begeeft, en kan een andere ontwikkelaar niet snel inspringen als ie ziek wordt of zichzelf met auto en al om een boom vouwt. Bij een bedrijf werken die overwegingen heel anders, ik wil gewoon dat dagelijks de laatste versie van al onze code op een beveiligde en goed gebackupte centrale server staat, dat hoort bij goede contingency planning.

En sja, dan gaat het over het netwerk, who cares? Op kantoor ligt gbit, VPN naar buiten is 50Mbit, iedereen die bij ons werkt heeft minimaal 25Mbit breedband thuis. Ik heb nog nooit langer op een commit gewacht dan een minuut, nou whooptidoo mooi koffiemoment. In ruil daarvoor staat het wel direct op RAID-5 en wordt het vannacht veilig gebackupt naar een fysiek gescheiden andere RAID-5. Dat vind ik stukken belangrijker dan 1 seconde besparen op de gemiddelde SVN-actie die we uitvoeren.

Maar inderdaad. Dingen als LDAP support is er eigenlijk nauwelijks. git heeft vanwege zijn decentrale natuur geen ACL ingebouwd.

Daarom zijn er dingen als gitolite bedacht, die op ssh niveau ACL toevoegd (en ook op repo niveau).

Voor de AD-authenticatie moet je feitelijk uitwijken naar git-smart-http (dan kun je het via Apache regelen via mod_ldap e.d.). Ik heb gitolite en gitosis snel afgeschreven, gitorious heb ik aan de gang gekregen maar nekte fundamenteel op whitespace in gebruikersnaam (iedereen heet bij ons in de AD gewoon "<voornaam> <achternaam>", wat redelijk normaal is). Uiteindelijk heb ik het via Redmine getunneld goed aan de gang gekregen, met AD-authenticatie en Redmine-autorisatie. Tot je er vervolgens achter komt dat alle clientside tools gebaseerd zijn op de commandline tools, en dus magistraal nekken op authenticatie zonder SSH-keys en bij iedere scheet user+pass vragen. Wat binnen een IDE als phpStorm niet werkt (en voluit hangt dus...) bij gebrek aan commandline invoeroptie.

Deze ernstige tekortkomingen kunnen pas opgelost worden als er een goede libgit is die custom integratie van IDE's e.d. toestaat. Helaas is libgit2 pas in early development, en staat op die pagina met goede reden expliciet "the current Git project has no stable or well-designed public API". Tot dat gefixt is tja, is Git wmb een mooie tool voor open source development, met veel individuele los contribuerende developers die niet bang zijn voor een potje commandline hacken. Maar niet serieus te nemen in corporate teams waar andere eisen gelden.

[Herko_ter_Horst]

n.m.

[ Voor 98% gewijzigd door Herko_ter_Horst op 09-10-2012 12:39 ]

[johnkeates]

Tsja Curry, in jouw geval gaat Git je niet helpen. Je hebt alles al voor elkaar, dus voor jou geen reden om uberhaupt ergens anders naar te kijken.

[alwinuzz]

Het grote voordeel van Git/Hg is toch branchen en mergen?

Als ik zie hoeveel tijd ik met één collega kwijt ben aan mergen met SVN, het zal wel een hel zijn met een groot team...
Dan lijkt Git me wel een uitkomst.

[compufreak88]

curry684 schreef op dinsdag 09 oktober 2012 @ 12:30:

[...]

Wat mensen vaak makkelijk over het hoofd zien: dat zie ik dus net zo sterk als nadeel als als voordeel, misschien nog wel sterker. Ik wil helemaal niet dat een ontwikkelaar een week offline werkt, want dan is ie een week werk kwijt als z'n harddisk het begeeft, en kan een andere ontwikkelaar niet snel inspringen als ie ziek wordt of zichzelf met auto en al om een boom vouwt. Bij een bedrijf werken die overwegingen heel anders, ik wil gewoon dat dagelijks de laatste versie van al onze code op een beveiligde en goed gebackupte centrale server staat, dat hoort bij goede contingency planning.

Als een ontwikkelaar een week niet commit in SVN, zit je met hetzelfde probleem. Dat heeft te maken met afspraken maken en nakomen.

En een SCM is primair niet bedoeld als backup tool (al wordt het daar wel vaak voor (mis)bruikt).

En sja, dan gaat het over het netwerk, who cares? Op kantoor ligt gbit, VPN naar buiten is 50Mbit, iedereen die bij ons werkt heeft minimaal 25Mbit breedband thuis. Ik heb nog nooit langer op een commit gewacht dan een minuut, nou whooptidoo mooi koffiemoment. In ruil daarvoor staat het wel direct op RAID-5 en wordt het vannacht veilig gebackupt naar een fysiek gescheiden andere RAID-5. Dat vind ik stukken belangrijker dan 1 seconde besparen op de gemiddelde SVN-actie die we uitvoeren.

Tjsah, ik merk bij mezelf dat als een bepaald commando langer duurt dan een paar seconden, ik al weer afgeleid ben van waar ik mee bezig was.

En wat als om een of andere reden die server tijdelijk down is? Kunnen developers dan hun hele SCM niet meer gebruiken?

[..]

Ik begrijp dat git vanuit een beheersstandpunt misschien niet de beste keuze is, maar vanuit een developers standpunt is dat het zeker wel.

[XyritZz]

alwinuzz schreef op dinsdag 09 oktober 2012 @ 13:25:
Het grote voordeel van Git/Hg is toch branchen en mergen?

Als ik zie hoeveel tijd ik met één collega kwijt ben aan mergen met SVN, het zal wel een hel zijn met een groot team...
Dan lijkt Git me wel een uitkomst.

Wat doet Git dan voor bijzonders qua mergen? Ik heb werkelijk waar nog nooit issues gehad met mergen in SVN, zelden onterecht een conflict gehad. Ook bij grotere projecten nooit problemen gehad.

[compufreak88]

XyritZz schreef op dinsdag 09 oktober 2012 @ 13:46:
[...]


Wat doet Git dan voor bijzonders qua mergen? Ik heb werkelijk waar nog nooit issues gehad met mergen in SVN, zelden onterecht een conflict gehad. Ook bij grotere projecten nooit problemen gehad.

SVN heeft wat dat betreft verbeteringen toegevoegd waardoor mergen tegenwoordig beter gaat. Maar het hele branch model van SVN is nog steeds erg beperkt en weinig flexibel.

[curry684]

compufreak88 schreef op dinsdag 09 oktober 2012 @ 13:30:
[...]

Als een ontwikkelaar een week niet commit in SVN, zit je met hetzelfde probleem. Dat heeft te maken met afspraken maken en nakomen.

Dat is het punt niet: SVN dwingt het af dat je regelmatig commit, Git juicht toe dat je lokaal werkt. Een belangrijk voordeel van Git komt te vervallen als je wil dat er regelmatig wordt gepusht op de centrale servers.

En een SCM is primair niet bedoeld als backup tool (al wordt het daar wel vaak voor (mis)bruikt).

Dat is feitelijk wel het primaire doel. Een superdeluxe backup tool die forks, branches en alle historische wijzigingen per ontwikkelaar backupt met toelichtingen van de reden erachter. En waar je ten allen tijde precies in kunt terugzoeken wie wat wanneer heeft veranderd, en desnoods ongedaan maken.

Tjsah, ik merk bij mezelf dat als een bepaald commando langer duurt dan een paar seconden, ik al weer afgeleid ben van waar ik mee bezig was.

Ik hoor vaker klachten over dat SVN traag zou zijn, en ik heb ze nooit herkend. Enige commando's waar ik ooit langer dan 'een paar seconden' op heb moeten wachten zijn fresh commits van een volledig nieuw project, en fresh checkouts. Wellicht heb ik gewoon wel de moeite genomen voor een goeie centrale infrastructuur ervoor met voldoende netwerk-, I/O en CPU power omdat we er zo van afhankelijk zijn

En wat als om een of andere reden die server tijdelijk down is? Kunnen developers dan hun hele SCM niet meer gebruiken?

Maar het is toch gewoon een vitale faciliteit die zo snel mogelijk wordt hersteld? Als je Exchange-server down is kun je ook even een uurtje niet mailen, dat moet je zien te voorkomen maar ok. Developer kan even een uurtje niet committen, tja, als dat een probleem is kun je gewoon met heartbeat en DRBD een HA-failoverende SVN-server opzetten. Het doet voor de vergelijking niets af aan dat je met Git dan ook een uur niet kunt pushen op de origin master.

Ik begrijp dat git vanuit een beheersstandpunt misschien niet de beste keuze is, maar vanuit een developers standpunt is dat het zeker wel.

Mijn developers willen gewoon niet merken dat er een SCM is. Die willen lekker coden, en lekker committen als er iets af is, en in de tussentijd zo min mogelijk merken dat dat ding er is tot ze het nodig hebben. Dat vereist naadloze IDE-integratie, intuitieve goedwerkende tools en SSO. Daar faalt Git nog hard mijns inziens.

Maar ik sta echt open voor dingen die ik gemist heb, johnkeates zegt wellicht wat sarcastisch bedoeld 'dat ik mijn zaakjes zo goed voor elkaar heb', maar dat is zogezegd mijn vraag juist: heb ik dat wel? Ben ik niet faliekant iets supergaafs aan het missen aan beschikbare tools die Git wel naadloos goed laten werken? Dat het conceptueel en inhoudelijktechnisch beter is dan SVN onderschrijf ik direct. Maar V2000 was ook technisch beter dan VHS, toch ging het grote publiek voor VHS. Uiteindelijk toonden ze allebei films en won VHS op de grotere keuze in goedkopere spelers en het bredere filmaanbod.

[Fuzzillogic]

Wij hebben vroeger (<2006, give or take) met SVN gewerkt. Na de overstap naar Mercurial echter nooit meer omgekeken. Met SVN had ik regelmatig ruzie met unclean work directories en gedoe met committen, en dus ook TortoiseSVN die niet altijd de status van icoontjes bij wilde werken (ja, het probleem speelt al lang). Nou zal het de toegenomen ervaring zijn, maar met Mercurial heb ik die problemen niet. Ongetwijfeld zal Subversion ondertussen ook nog verbeterd zijn.

Dat een DVCS minder uitnodigt om te gaan pushen dan een VCS als Subversion klopt niet echt. Omdat je lokaal werkt, makkelijk eigen branches kunt aanmaken en kunt rebasen zonder dat je daarmee potentieel je collega's in de weg zit maakt het juist prettig en makkelijk om gewoon tussendoor te committen. Desgewenst zou je kunnen scripten dat na een commit automatisch ook naar een speciale backup-repository wordt gepusht.

Dat SVN wel eens traag kan zijn kan ik beamen, iets wat Mercurial op lokale SSD nooit last van heeft.

IDE integratie van Mercurial is uitstekend. Netbeans, sowieso een warme aanrader, is zelf gehost in een Mercurial repository, dus Hg-support zit er OOTB in. (SVN en Git tegenwoordig ook). TFS integratie in VS2008/2010 daarentegen laat me de tranen in de ogen schieten. Helemaal als je ziet wat ze er nog voor durven te vragen.

[Snake]

Git moet je via Command Line doen. Een deel basisacties gaan via diverse UIs, maar voor het geavanceerde werk (lees: het werk waarbij je echt Git gebruikt voorwat het gebouwd is) heb je toch de commandline nodig (of een of ander draconisch gedesignede UI).

Dan: Git is inderdaad gebouwd rond het lokaal commiten, het is je eigen keuze, je kan zo vaak pushen als je wilt. Wil je een backup, dan branch je lokaal, werk je daar op en push je die branch naar de server. Geen probleem.

Overigens een tip voor iedereen, zet

git config core.autocrlf false

Git (en enig ander source control systeem) hoort je files niet te wijzigen.

[ Voor 13% gewijzigd door Snake op 09-10-2012 18:37 ]

[compufreak88]

@snake beter is het om dit via een .gig attributes of bestand te doen omdat het dan ook oor iedereen gelijk is. Anders kan het een grote rommel opleveren.