/u/197564/crop6072aa9bcdaaf.png?f=community)
👉🏻 Blog 👈🏻
/u/12668/hydra.png?f=community)
:strip_icc():strip_exif()/u/492949/crop627d0c893ea0e_cropped.jpg?f=community)
/u/470671/elephant.png?f=community)
Hier stuiten we denk ik op een belangrijk verschil in filosofie. Als dev, juist als dev, vind ik vrijwel iedere user error die veelvuldig voorkomt een fout in het design van de software. Het is leuk dat het gefixt kan worden, maar het blijft neerkomen op dat ik een heleboel van mijn tijd, energie, en aandacht moet besteden aan het bedenken wat git van mij wil, in plaats van dat het al werkt op een manier die aansluit bij mijn manier van doen.
Nou wil ik best erkennen dat het niet eenvoudig is om iets te maken dat goed aansluit bij de gebruikers... maar er zijn wel mogelijkheden.
Sla de aanmatigendheid maar over, ik weet best waar version control voor is. Maar ook history, blame en dat soort dingen zijn vooral nuttig in contexten waar dingen mis gaan. (Bovendien heb je voor dergelijke basis dingen niet zoveel complexiteit nodig.
Zeker, het helpt ook wel om af en toe de code van anderen door te kijken als preventief middel, en soms is de geschiedenis ook best interessant op zich, maar dat is toch echt een stuk minder in tijd en een stuk minder in belangrijkheid.
Nogmaals: blijkbaar dus niet. Ik denk niet dat je hier zonder checkout kunt.
Nee, dat is het dus niet. Want interfaces en abstract classes zijn dingen die mijn doel zijn (nou ja, niet echt, omdat mijn focus op wat andere terreinen zijn) maar ze zijn deel zeg maar van de 'productie', van het eindresultaat. Git is een tool, geen doel op zich. Dat is een fundamenteel verschil.
(Maar ook wat code betreft heb ik de neiging om te gaan voor saai en degelijk, en niet voor de meest esoterische flexibele mogelijkheden van een taal.)
Het is aanmatigend en het blijft aanmatigend.Mooie stropop . Maar eh, beginners die meelezen: version control is nuttig en belangrijk, maar laat je niet aanpraten dat het altijd aan jou ligt als software complex is en veel tijd kost en een gigantische learning curve heeft. Soms is dat gewoon een resultaat van slecht design (of van design met hele andere prioriteiten dan die jij hebt.)
Dat maakt je niet minderwaardig, geen mindere ontwikkelaar, niet gek - helaas is de sfeer in de IT nogal eens erg gericht op het op een voetstuk plaatsen van kunstmatige en onnodige barrieres als een soort test van geschiktheid.
En daarom kijgen we veel software die weinig snapt van gebruikers, want daar kijkt men nogal op neer.
Hydra, ik ben bang dat ik je mening niet kan veranderen, maar ik hoop hiermee te voorkomen dat toekomstige IT'ers die rare houding internaliseren.
Never explain with stupidity where malice is a better explanation
Waarom? Een dev die in teamverband niet met versiebeheer kan of wil werken heeft een manco en niet de voorkeur. Dat is toch de realiteit? Dan kies ik liever iemand die er wel fatsoenlijk mee kan werken.:
👉🏻 Blog 👈🏻
/u/26735/crop5b6e03049ac12.png?f=community)
?
Ik denk dat het er eerder iets mee te maken heeft dat Linus Torvalds er iets mee te maken heeft. Briljant maar...
👉🏻 Blog 👈🏻
Verwijderd
Ik zei alleen maar wat mij ooit is verteld, maar met Linus Torvalds is het logisch inderdaad…:
[...]
?
Ik denk dat het er eerder iets mee te maken heeft dat Linus Torvalds er iets mee te maken heeft. Briljant maar...
[video]
[ Voor 6% gewijzigd door Verwijderd op 12-02-2017 21:27 ]
:strip_icc():strip_exif()/u/6607/klootviool2.jpg?f=community)
Voornamelijk dat ik makkelijk iets terug kan zetten als ik bedenk dat iets niet is zoals ik wil, maar ik ook niet meteen al mijn code weg wil gooien. Volgens mij treden conflicten en problemen bv op (maar ik heb nu niet een kant-en-klare lijst met problemen paraat) als je git commit v3 doet, dan git commit v4, en dan git checkout v3 en dat dan weer wilt committen.
(Ah, nee, kijk: http://stackoverflow.com/...tory-to-a-previous-commit
Dan ben ik er in elk geval achter waar de verwarring vandaan komt: in mijn hoofd is het inhoudelijk vrijwel hetzelfde om uncommitted en committed changes te veranderen. Gewoon: je gaat voorwaarts in de tijd, je construeert je nieuwe werkelijkheid en dat is het nieuwe normaal. Dus commit en be done with it. Maar bij committed changes moet je reverten maar kun je niet checkout gebruiken, en bij uncommitted changes kun je niet reverten en moet je checkout gebruiken, en als je een combinatie van beide hebt, dan.... eerst checkout en dan revert misschien?)
Misschien dat het vanuit het model van git bezien logisch is, maar ik vind zelf dus dat je model altijd zo dicht mogelijk bij de werkelijkheid moet blijven, en niet andersom.
De merge-problemen uit https://reprog.wordpress....ith-added-actual-reasons/ ben ik trouwens ook al eens tegengekomen.
En tegelijkertijd kom ik deze problemen dus niet vaak genoeg tegen om precies te onthouden hoe dat allemaal werkt (of om een actueel lijstje te kunnen geven op het moment dat de discussie optreedt.)
Dat is ten eerste een kwestie van herhaling: om complexe dingen actueel te houden, heb je oefening nodig. Als ik maanden geen mysql doe, heb ik echt weer even nodig om het tot in detail te snappen. Idem voor javascript - een deel ervan zit er nog wel, maar ligt niet meer aan de oppervlakte als ik het een tijd niet gebruik.
Ten tweede is er het punt van context switching: als ik in mijn hoofd de code actueel heb, dan verdwijnt het git mental model even naar de achtergrond. Dat is waarom het als ik er dedicated tijd aan besteed en bijvoorbeeld een testrepo doe veel minder problemen heb: dan staat git front en center. Maar bij het programmeren heb ik die mentale ruimte dus al voor iets anders actief.
Het punt is: ik heb geen zin om (bv wekelijks) oefensessies te gaan houden om mijn git-complexe-situaties-skill up-to-date te houden. Want javascript en mysql zijn onderdeel van wat ik daadwerkelijk doe, het programmeren zelf, maar git is een tool die vooral faciliterend moet zijn. Als ik moet kiezen waar ik mijn studietijd aan wil besteden, dan is het iedere keer weer het vakinhoudelijke deel.
Ik heb me er voor de gein overigens in verdiept, en ik ben blijkbaar zeker niet de enige die het zo vindt. En ik denk dat het deels gewoon jammer is dat er te vaak wordt herhaald dat git fantastisch is als je het eenmaal weet - en dat dat voor veel mensen (/situaties) gewoon niet zo is wordt te snel op de persoon gespeeld.
Als ik me daar jaren terug bewust van was geweest had ik beslist meer druk gezet op het kiezen van een ander vcs, omdat het gewoon niet echt de mogelijkheid heeft om het op een simpele manier te gebruiken.
Je komt al heel snel in de buurt van de complexe dingen: een detached head bv is simpel gecreerd, en uitvogelen hoe je dat herstelt zonder code loss is niet echt zo simpel als add-commit-push. (En ik dacht dus echt iets heel onschuldigs te doen.)
Maar daarmee is het eigenlijk niet de beste oplossing ons scenario, en het is jammer dat dat niet eerder duidelijk was. (En je weet pas dat het blijkbaar niet lukt om dingen na een steile learning curve te leren als het niet gelukt is en het dus al heel veel uren heeft gekost. Het is vrijwel onmogelijk om dat soort dingen vooraf realistisch in te schatten omdat je niet weet wat je nog niet weet.)
Wat een constructieve inhoudelijke reactie. De IT is zo'n fijne, respectvolle sector.:
[...]
Never explain with stupidity where malice is a better explanation
Het is kennelijk vooral de opdeling en benaming van de verschillende commando's (en opties) wat je dwars zit ?
Misschien dat mecurial je dan meer ligt (opzich wel vaker ergens gelezen dat er mensen waren die dat gebruikersvriendelijker vonden).
Het blijft semi-low-level annoteren en hacken van een graph, maar als het goed is doet een revert op een
uncommitted file daar wel wat je wilt.
Achja een hele briljante opmerking was het dan misschien ook wel niet, of denk je werkelijk dat bijvb. de linux-kernel in elkaar geklooid wordt door een aantal managers en een stel sys-admins ?
Maarja ... forum is net als git, lastig om de history nu nog te rewriten
Overigens vraag ik me dan af of mysql ook niet een martelgang moet zijn. Je krijgt of de verkeerde data terug omdat je de verkeerde vraag gesteld had, of een ook niet altijd even duidelijke foutmelding, of in het geval van Mysql ook nog eens de kans op arbitraire data (er vanuitgaande dat ze bij groupby's er nog steeds potentieel een zooitje van maken). Dan ben je uiteindelijk misschien toch ondanks dat het ook niet ideaal is, beter af met een horkerige tool die iets weigert uit te voeren omdat het wellicht ambigu is wat je bedoeld.
Er zijn best zaken die gebruiksvriendelijker zouden kunnen, sommige daarvan worden al geadresseerd in third party GUI's, andere zijn misschien ook gewoon niet zo eenvoudig als het lijkt (zeker niet in het niet generieke non-lineaire history geval).
[ Voor 11% gewijzigd door gekkie op 12-02-2017 22:30 ]
:strip_icc():strip_exif()/u/68028/crop5c0ef8207f712_cropped.jpeg?f=community)
Volgens mij mis je de de big picture van software development.
Heb je het artikel "expert beginner" van hierboven gelezen?
Heb je het artikel "expert beginner" van hierboven gelezen?
👉🏻 Blog 👈🏻
/u/155568/usericon.png?f=community)
Je kunt ook het repository op die server als remote op je lokale station instellen, dan kun je er gewoon naar pushen. DVCS FTW
Wat is de big picture volgens jou? (Mij lijkt het dat het ligt op het ontwikkelen van software die goed te gebruiken is, maar misschien heb ik dat mis.)
Ja. Ik ben geen 'expert beginner', ik ben zeker ook geen expert - ik ben slechts iemand die vind dat de prioriteiten in de IT te vaak liggen op een soort van morele tests en het aangeven waarom anderen minderwaardig zijn (als dev, als gebruiker...)Heb je het artikel "expert beginner" van hierboven gelezen?
Ik zie een steile learning curve, en vind dat mogelijk slecht design. Ik vind het mijn vak om dat - in de software waar ik bij betrokken ben - beter te doen waar ik kan. Anderen zien een steile learning curve en zien dat als iets van waarde, als iets om anderen mee neer te halen, 'dat je dat niet eens kunt, dan verdien je het niet om dev te zijn! Je bent expert beginner die niet meer wil leren! Je bent dom, iedereen kan dat! Je werkomgeving is slecht!'
Ik vind het nogal tekenend - en zorgelijker dan die 12 stappen.
Never explain with stupidity where malice is a better explanation
Omdat het niet echt ingegeven lijkt te zijn als basis voor een fijn en gelijkwaardig gesprek. Waarom zou ik dat soort vragen beantwoorden aan iemand die het eerder nodig vond om op aanmatigende toon mij van ongevraagd carriereadvies te voorzien, iets constructiefs als
plaatste, en schreef dat ik mezelf enorm belachelijk maakte?
Never explain with stupidity where malice is a better explanation
Wat ik overigens nog wel mis, of misschien weet ik gewoon niet hoe dat moet ...
Stel ik pas wat dingen aan heb binnen SourceTree dan netjes de 'unstashed' files. Alleen heb ik dat in de 'develop' branch gedaan en wil eigenlijk een nieuwe branch maken (git-flow -> start new feature) dan moet ik eerst deze bestanden 'stashen' (en committen dacht ik).
Nu heeft PhpStorm een 'shelf' functie, waardoor ik de wijzigingen even in PhpStorm kan opslaan, dan een nieuwe branch aan kan maken en die changes dan 'unshelf' in de nieuwe branch.
Maar kan dat ook gewoon in SourceTree?
...Stel ik pas wat dingen aan heb binnen SourceTree dan netjes de 'unstashed' files. Alleen heb ik dat in de 'develop' branch gedaan en wil eigenlijk een nieuwe branch maken (git-flow -> start new feature) dan moet ik eerst deze bestanden 'stashen' (en committen dacht ik).
Nu heeft PhpStorm een 'shelf' functie, waardoor ik de wijzigingen even in PhpStorm kan opslaan, dan een nieuwe branch aan kan maken en die changes dan 'unshelf' in de nieuwe branch.
Maar kan dat ook gewoon in SourceTree?
Ik ken sourcetree niet maar je kunt een changeset gewoon met "git stash" opbergen, een andere branch uitcheckken (git checkout dev), updaten (git pull), daarop een nieuwe feature branch maken (git checkout -b <naam>) en dan de changes terugzetten ("git stash pop").:
Maar kan dat ook gewoon in SourceTree?
Ik weet niet wat het sourcetree equivalent daarvan is maar ik neem aan dat dat ook allemaal kan. Ik vind het alleen zelf gewoon efficienter 't in te typen.
https://niels.nu
/u/3813/100_8985_ICON2.JPG?f=community)
Somniferous whisperings of scarlet fields. Sleep calling me and in my dreams i wander. My reality is abandoned (I traverse afar). Not a care if I never everwake.
/u/122874/crop5e26d7a209cd1_cropped.png?f=community)
Vraag me toch af hoe dit topic heeft kunnen ontsporen om het nut van versie beheer aan te tonen 
Ik gebruik zelfs Git voor mijn persoonlijke hobby projecten, tuurlijk kom ik ook bij klanten waar geen Git gebruikt wordt maar er is ALTIJD een VCS. Vaak bij Microsoft georiënteerde projecten is het TFS (of in het ergste geval SVN
)
Maar Git is absoluut niet alleen een veiligheidsnet, integendeel, het is een essentieel onderdeel van je workflow als developer.
Verder dient Git ook niet als een backup van je code, daar heb je backups van je Git repo voor
Ik gebruik zelfs Git voor mijn persoonlijke hobby projecten, tuurlijk kom ik ook bij klanten waar geen Git gebruikt wordt maar er is ALTIJD een VCS. Vaak bij Microsoft georiënteerde projecten is het TFS (of in het ergste geval SVN
)Maar Git is absoluut niet alleen een veiligheidsnet, integendeel, het is een essentieel onderdeel van je workflow als developer.
Verder dient Git ook niet als een backup van je code, daar heb je backups van je Git repo voor
Misschien omdat mensen denken dat het gaat om het nut van versiebeheer aan te tonen, terwijl volgens mij niemand het daarmee oneens is.:
Vraag me toch af hoe dit topic heeft kunnen ontsporen om het nut van versie beheer aan te tonen
Ik ben helemaal voor versiebeheer. Ik heb het alleen graag in een vriendelijk, behulpzaam pakket ipv iets dat enorme overhead kost aan investeringen in de learning curve en het up-to-date houden van vaardigheden.
Als daar wat aan te doen is, dan zou ik helemaal gelukkig zijn. (Dus een cursus Git gegeven door mensen die iets weten van verschillende leerstijlen van mensen en hoe je daarbij aan kunt sluiten, en die kunnen helpen met hoe je de impact van context switching en retention kunt minimaliseren? Graag!)
Wel vraag ik me dus af waarom een versiebeheer niet zou dienen als veiligheidsnet. Uit het git handbook nota bene:
Onderdeel van de vele redenen om VCS te gebruiken. Alleen ik ben het dus niet eens met de laatste statement: dat je dat allemaal krijgt door erg weinig overhead. Voor mij is de overhead (namelijk de tijd die ik moet besteden aan het verkrijgen en onderhouden van vaardigheden voor git) niet 'very little' maar behoorlijk.
En in de tussentijd heeft het gebruik van Git vaker tot het verlies van code geleid dan het dat heeft voorkomen. En dat is wel degelijk een probleem want dat is in elk geval niet waar ik het voor gebruik.
Never explain with stupidity where malice is a better explanation
Mag ik vragen hoe je dat voor elkaar gekregen hebt? Want hoeveel ik ook probeer, is er altijd wel een staat van de file/change terug te vinden
Enige wat ik me kan indenken is dat je voor de lol een force-push doet over een [x behind] heen ... waardoor je indd oude changes gewoon weg kan gooien. Probleem daarmee is alleen dat een standaard git setup gewoon een warning gooit als je dat doet. (Buiten het feit dat je zelfs dan nog via je working copy terug kan maar dat is een andere discussie).
Zoals ik het nu namelijk lees probeer je een VCS te gebruiken als backup van je code... het is een mooie extra functie maar niet het hoofddoel
"Generally", nogal een sleutelwoord hier... als je het dus niet zo inricht dat het mogelijk is ben je inderdaad alsnog je files kwijt (moet je wel wat moeite voor doen ...)
Edit: Hoeft niet specifiek HEAD te zijn
:strip_exif()/u/15045/got_hamster.gif?f=community)
Heel eerlijk: ik herken de reactie van incaz wel. Ik denk ook dat het behoorlijk afhangt van de omgeving waarin je werkt, welke tools je gebruikt en wat de bedrijfscultuur is.
Zelf werk ik bij een bedrijf wat in enkele jaren veranderd is van volledig monolith .NET + workflow op basis van TFS, naar een omgeving die veel variatie bevat (verschillende programmeertalen, verschillende soort data storage, micro-services, cloud, etc) gecombineerd met een workflow op basis van Git. Destijds was een van de eerste stappen om van TFS over te gaan naar Git en dit leidde tot exact dezelfde discussies. Er waren binnen alle teams wel mensen die niet zomaar uit zichzelf Git aanleerden en ook gemotiveerd moesten worden om over te stappen. Naarmate meer collegas git leerden verspreidde de kennis en het git gebruik zich als een olievlek. En ja, dan gebeurde dus ook deze dingen:
* "Ik ben mijn code kwijt"
* "Ik zie mijn code niet in het centrale repository"
* "Ik deed force push en nu is xyz kapot"
* "Hoe maak ik een branch?"
* "Ik doe een checkout en alle files zijn gewijzigd" (cross-platform en LF vs CRLF)
Ja, met Git kun je dingen kapot maken en er is een bepaalde leercurve.
Tegenwoordig zie binnen het bedrijf echt helemaal niemand problemen hebben met Git. 99.5% van de tijd zijn het ook alleen simpele operaties (pull, branch, commit, push, checkout master), deels omdat de workflow er om heen complexiteit vermijd. Alle teams gebruiken pull requests om code te reviewen (ook van mensen buiten het team), merges vinden binnen BitBucket/GitHub plaats. CI/CD is geautomatiseerd (typisch Gitflow of golden master aanpak). Op onze GitHub repositories doen we squash & merge, op BitBucket staan we toe dat de commit history 'lelijk' is omdat de onvoldoende mensen snappen wat een rebase nu eigenlijk is. Laat staan het kunnen uitvoeren. We hebben meer dan 700 repos. Ik heb de CVs van de laatste 10 sollicitanten bekeken: 9 van de 10 hebben al met Git gewerkt. Geen ervaring met Git is geen breekpunt, maar we maken wel duidelijk dat dit onze standaard is.
Het leren van Git kost inderdaad een aantal uur per persoon, plus effort voor de conversie, aanpassingen in tooling, etc. Tegelijk krijg je de mogelijkheid (niet gratis, kost ook tijd) om de workflow dusdanig te stroomlijnen. Niet zozeer de flow van het daadwerkelijke committen, maar juist de flow van code reviews, het wegnemen van de constante verbinding met TFS/SVN, de uitgebreidere scripting/integratie mogelijkheden. Daarom denk ik juist dat de omgeving heel belangrijk is: als je in een relatief kleine omgeving werkt, met slechts enkele vaste repos, met een bestaande workflow, de TFS server onder je bureau, geen reden om deel te nemen in bijv. open source... ja, ik kan me dan best wel voorstellen dat het veranderen van deze zaken geen prioriteit heeft en het gebruik van Git juist een complexere manier van werken is. Ik kan me ook voorstellen dat dit naar anderen toe over kan komen als 'vastgeroest zitten'. Misschien wel, misschien niet.
Fun fact: ik heb een collega die nog steeds bij iedere story eerst in BitBucket een branch maakt, vervolgens lokaal het repo ophaalt en naar die branch wisselt. Ach ja, als het voor hem werkt...
Wat betreft het oorspronkelijke topic: command line voor alles, behalve commit/merge/diff. Die doe ik met TortoiseGit, omdat ik juist die tool (net zoals SubversionGit) een hele goede conflict resolution vind hebben. Ik weet niet precies waarom, maar waar andere tooling bij sommige zaken een merge conflict geven, kan TortoiseGit deze juist zonder problemen mergen. Heeft me tot nu toe veel tijd bespaard
Zelf werk ik bij een bedrijf wat in enkele jaren veranderd is van volledig monolith .NET + workflow op basis van TFS, naar een omgeving die veel variatie bevat (verschillende programmeertalen, verschillende soort data storage, micro-services, cloud, etc) gecombineerd met een workflow op basis van Git. Destijds was een van de eerste stappen om van TFS over te gaan naar Git en dit leidde tot exact dezelfde discussies. Er waren binnen alle teams wel mensen die niet zomaar uit zichzelf Git aanleerden en ook gemotiveerd moesten worden om over te stappen. Naarmate meer collegas git leerden verspreidde de kennis en het git gebruik zich als een olievlek. En ja, dan gebeurde dus ook deze dingen:
* "Ik ben mijn code kwijt"
* "Ik zie mijn code niet in het centrale repository"
* "Ik deed force push en nu is xyz kapot"
* "Hoe maak ik een branch?"
* "Ik doe een checkout en alle files zijn gewijzigd" (cross-platform en LF vs CRLF)
Ja, met Git kun je dingen kapot maken en er is een bepaalde leercurve.
Tegenwoordig zie binnen het bedrijf echt helemaal niemand problemen hebben met Git. 99.5% van de tijd zijn het ook alleen simpele operaties (pull, branch, commit, push, checkout master), deels omdat de workflow er om heen complexiteit vermijd. Alle teams gebruiken pull requests om code te reviewen (ook van mensen buiten het team), merges vinden binnen BitBucket/GitHub plaats. CI/CD is geautomatiseerd (typisch Gitflow of golden master aanpak). Op onze GitHub repositories doen we squash & merge, op BitBucket staan we toe dat de commit history 'lelijk' is omdat de onvoldoende mensen snappen wat een rebase nu eigenlijk is. Laat staan het kunnen uitvoeren. We hebben meer dan 700 repos. Ik heb de CVs van de laatste 10 sollicitanten bekeken: 9 van de 10 hebben al met Git gewerkt. Geen ervaring met Git is geen breekpunt, maar we maken wel duidelijk dat dit onze standaard is.
Het leren van Git kost inderdaad een aantal uur per persoon, plus effort voor de conversie, aanpassingen in tooling, etc. Tegelijk krijg je de mogelijkheid (niet gratis, kost ook tijd) om de workflow dusdanig te stroomlijnen. Niet zozeer de flow van het daadwerkelijke committen, maar juist de flow van code reviews, het wegnemen van de constante verbinding met TFS/SVN, de uitgebreidere scripting/integratie mogelijkheden. Daarom denk ik juist dat de omgeving heel belangrijk is: als je in een relatief kleine omgeving werkt, met slechts enkele vaste repos, met een bestaande workflow, de TFS server onder je bureau, geen reden om deel te nemen in bijv. open source... ja, ik kan me dan best wel voorstellen dat het veranderen van deze zaken geen prioriteit heeft en het gebruik van Git juist een complexere manier van werken is. Ik kan me ook voorstellen dat dit naar anderen toe over kan komen als 'vastgeroest zitten'. Misschien wel, misschien niet.
Fun fact: ik heb een collega die nog steeds bij iedere story eerst in BitBucket een branch maakt, vervolgens lokaal het repo ophaalt en naar die branch wisselt. Ach ja, als het voor hem werkt...
Wat betreft het oorspronkelijke topic: command line voor alles, behalve commit/merge/diff. Die doe ik met TortoiseGit, omdat ik juist die tool (net zoals SubversionGit) een hele goede conflict resolution vind hebben. Ik weet niet precies waarom, maar waar andere tooling bij sommige zaken een merge conflict geven, kan TortoiseGit deze juist zonder problemen mergen. Heeft me tot nu toe veel tijd bespaard
Programmer's Drinking Song: 99 little bugs in the code, 99 bugs in the code, Fix one bug, compile it again, 100 little bugs in the code. (go to start if bugs>0)
Klopt, er is een leer curve. Dat is met alles zo. Tevens is alleen het laatste punt een algemene irritatie vwb cross platform programming
Denk dat we daar nooit vanaf komen tot iedereen dezelfde code standaard hanteert Maar kan je dat eerste punt is uitlichten, Bij mij op kantoor hebben we dat eigenlijk nooit gehad (na transfer van SVN --> Git). De rest is wel te begrijpen, hoort bij de leercurve
Voor CLI kan je is kijken naar OhMyZsh, heeft een mooie lijst aan aliases voor makkelijk gebruik van Git.:
Wat betreft het oorspronkelijke topic: command line voor alles, behalve commit/merge/diff. Die doe ik met TortoiseGit, omdat ik juist die tool (net zoals SubversionGit) een hele goede conflict resolution vind hebben. Ik weet niet precies waarom, maar waar andere tooling bij sommige zaken een merge conflict geven, kan TortoiseGit deze juist zonder problemen mergen. Heeft me tot nu toe veel tijd bespaard
En ik vind persoonlijk de diff tools eigenlijk allemaal ontoereikend, kan via CLI het sneller doorlezen dan via GUI
[ Voor 0% gewijzigd door Rushleader op 14-02-2017 13:11 . Reden: Typos =.= ]
Code kwijt, bedoel je? Dat waren altijd fouten van de user zelf, meestal een combinatie van gebrek aan kennis en dan het verkeerde commando geven. Bijvoorbeeld een branch -D deleten. Ik kan me niet herinneren dat de code ooit ook echt verloren is gegaan, het is dan inderdaad even puzzelen om de juiste commando's te achterhalen.
De LR/CRLF fout werd trouwens gedeeltelijk veroorzaakt doordat de migratie TFS -> Git eerst gedeeltelijk via Windows nodes verliep, maar later via Linux nodes (het complete verhaal: TFS werd enkele maanden naar Git repos gesynchroniseerd om de nieuwe CI/CD stack op te bouwen. Synchronisatie ging per commit. Aan het einde van de rit TFS uitgezet en waren we over). Na de migratie hebben we met de juiste settings en gitattribute files het wel opgelost in de getroffen repos.
Thx, zal er eens naar kijken:
Voor CLI kan je is kijken naar OhMyZsh, heeft een mooie lijst aan aliases voor makkelijk gebruik van Git.
En ik vind persoonlijk de diff tools eigenlijk allemaal ontoereikend, kan via CLI het sneller doorlezen dan via GUI
Programmer's Drinking Song: 99 little bugs in the code, 99 bugs in the code, Fix one bug, compile it again, 100 little bugs in the code. (go to start if bugs>0)
:strip_icc():strip_exif()/u/76637/200px-Sardaukar_Insignia-Dune.jpg?f=community)
:strip_exif()/u/52746/eric-cartman_small.gif?f=community)
Geweldig die hele discussie over git
Ik werk in een bedrijf dat vrijwel helemaal bouwt op Microsoft .NET en wij gebruiken nog steeds *trommelgeroffel* SourceSafe
Zelf heb ik al meerdere malen uitgezocht hoe we over kunnen naar git en thuis gebruik ik git (en github) sowieso.
De redenen dat we nog niet zover zijn:
- Mensen zijn gewend aan het checkout en locken systeem. Mergen vinden ze eng.
- Mergen werkt ook voor geen meter met de huidige projecten (Visual Studio projectfiles mergen niet lekker, zeker niet bij gigantische Windows Forms applicaties met tig dependencies). Dit zou in Visual Studio 2017 beter moeten worden, als we eindelijk met wildcards kunnen werken voor bestanden.
- Mensen zijn gewend aan een centrale repository. Waar ze nu gewoon iets uitchecken, editen en weer inchecken... zullen ze bij git het eerst lokaal moeten committen en daarna - na eventueel te mergen - het moeten pushen naar een bare repository. Dit vergt meer kennis. Ook van collega's die 60+ zijn, maar nog wel belangrijk werk doen.
- Last but not least: we werken veel met project references, zodat we code snel kunnen aanpassen in verschillende lagen van onze pakketten. Onze code is daardoor niet netjes volgens een boomstructuur ingericht, wat het moeilijk maakt om duidelijke "projecten voor git" in te richten. Dit is wel op te lossen door gedeelde libraries in aparte git repositories te plaatsen, en NuGet te gaan gebruiken om deze te referencen (dus stoppen met project references voor cross solution libraries), en vervolgens de specifieke projecten voor bepaalde solutions wel netjes onder te brengen in dezelfde tree.
Dit laatste zou grote voordelen voor ons kunnen bieden (eindelijk duidelijke changesets per solution), maar is ook tering veel werk.
Onze workflow is vooral erg ad hoc overigens.
Om dan toch weer on topic te gaan, welke git clients gebruik ik het liefste?
Ik heb voldoende kennis van git om gewoon de command line te gebruiken. Daarnaast gebruik ik gewoon de geïntegreerde clients van Visual Studio en VS Code.
PS:
Zelf ben ik ook fan van de GO Git Service (gogs.io). Die gebruik ik om thuis mijn eigen github achtige server te hebben Super handig voor projecten die je niet met de wereld wil delen.
Ik werk in een bedrijf dat vrijwel helemaal bouwt op Microsoft .NET en wij gebruiken nog steeds *trommelgeroffel* SourceSafe
Zelf heb ik al meerdere malen uitgezocht hoe we over kunnen naar git en thuis gebruik ik git (en github) sowieso.
De redenen dat we nog niet zover zijn:
- Mensen zijn gewend aan het checkout en locken systeem. Mergen vinden ze eng.
- Mergen werkt ook voor geen meter met de huidige projecten (Visual Studio projectfiles mergen niet lekker, zeker niet bij gigantische Windows Forms applicaties met tig dependencies). Dit zou in Visual Studio 2017 beter moeten worden, als we eindelijk met wildcards kunnen werken voor bestanden.
- Mensen zijn gewend aan een centrale repository. Waar ze nu gewoon iets uitchecken, editen en weer inchecken... zullen ze bij git het eerst lokaal moeten committen en daarna - na eventueel te mergen - het moeten pushen naar een bare repository. Dit vergt meer kennis. Ook van collega's die 60+ zijn, maar nog wel belangrijk werk doen.
- Last but not least: we werken veel met project references, zodat we code snel kunnen aanpassen in verschillende lagen van onze pakketten. Onze code is daardoor niet netjes volgens een boomstructuur ingericht, wat het moeilijk maakt om duidelijke "projecten voor git" in te richten. Dit is wel op te lossen door gedeelde libraries in aparte git repositories te plaatsen, en NuGet te gaan gebruiken om deze te referencen (dus stoppen met project references voor cross solution libraries), en vervolgens de specifieke projecten voor bepaalde solutions wel netjes onder te brengen in dezelfde tree.
Dit laatste zou grote voordelen voor ons kunnen bieden (eindelijk duidelijke changesets per solution), maar is ook tering veel werk.
Onze workflow is vooral erg ad hoc overigens.
Om dan toch weer on topic te gaan, welke git clients gebruik ik het liefste?
Ik heb voldoende kennis van git om gewoon de command line te gebruiken. Daarnaast gebruik ik gewoon de geïntegreerde clients van Visual Studio en VS Code.
PS:
Zelf ben ik ook fan van de GO Git Service (gogs.io). Die gebruik ik om thuis mijn eigen github achtige server te hebben
Super handig voor projecten die je niet met de wereld wil delen.
Ask yourself if you are happy and then you cease to be.
SourceSafe? Volgens mij heb ik daar het laatst in 2000 nog mee gewerkt. Gecondoleerd:
Geweldig die hele discussie over git
Ik werk in een bedrijf dat vrijwel helemaal bouwt op Microsoft .NET en wij gebruiken nog steeds *trommelgeroffel* SourceSafe
Het engste vond ik altijd dat er bij grote databases werd aangeraden om regelmatig een 'ss analyze' te draaien om problemen te detecteren/op te lossen. We deden dit tijdens een nachtelijke batch en elke ochtend zag ik in de log wel enge meldingen voorbij komen. Ik had nooit het vertrouwen dat ik altijd terug kon gaan naar elke voorgaande commit.
Tsja, dit is typisch een voorbeeld van iets dat zo gegroeid is en wat gewoon een enorme hoeveelheid werk zou kosten om vanaf te komen. En die energie kunnen we beter aan onze producten besteden.:
[...]
SourceSafe? Volgens mij heb ik daar het laatst in 2000 nog mee gewerkt. Gecondoleerd
Het engste vond ik altijd dat er bij grote databases werd aangeraden om regelmatig een 'ss analyze' te draaien om problemen te detecteren/op te lossen. We deden dit tijdens een nachtelijke batch en elke ochtend zag ik in de log wel enge meldingen voorbij komen. Ik had nooit het vertrouwen dat ik altijd terug kon gaan naar elke voorgaande commit.
Wel maken we elke nacht back-ups van SourceSafe. En ja, we maken ons ook zorgen om de betrouwbaarheid.
Ik ben wel begonnen met een eerste opzet om NuGet intern te gaan gebruiken om projecten los te koppelen van elkaar. Zodra we zover zijn, zouden we langzamerhand wat projecten kunnen verhuizen naar git.
Maar ik ben wel bang dat we dan vrij lang in zo'n situatie blijven hangen waarbij niet alle code bij elkaar staat en dat is ook vervelend.
Overigens hebben we ook nog een groot VB6 project draaien bij klanten
Ask yourself if you are happy and then you cease to be.
Ik gebruik gewoon Bitbucket. Hoef ik zelf de hosting niet te regelen en met webhooks/pipelines kun je ook builds op je serveer triggeren bijvoorbeeld.
Idem. We hadden ook de regel ingesteld dat je als je vergat een file te unlocken chocolade mee moest nemen:
SourceSafe? Volgens mij heb ik daar het laatst in 2000 nog mee gewerkt. Gecondoleerd
Fink aangekomen toen
Tja. Ik vind dat gewoon een slap excuus. Als je met de developers vindt dat je over moet, moet het gewoon gebeuren. Kun je het beter eerder dan later doen, dan heb je er sneller profijt van. Daarnaast kost het maken van een git-repo gewoon geen tijd. Het importeren van SS history is misschien lastiger maar dan kun je ook gewoon die SS repo laten bestaan in een read-only mode. Iets minder handig misschien, maar een git repo maken is een paar minuten werk,
[ Voor 36% gewijzigd door Hydra op 14-02-2017 14:52 ]
https://niels.nu
Ja, mensen die op vakantie gingen en nog ergens een lock hadden staan. Altijd leuk!:
[...]
Idem. We hadden ook de regel ingesteld dat je als je vergat een file te unlocken chocolade mee moest nemen
Gelukkig had ik ook het wachtwoord om die lock weer genadeloos te verwijderen.
Het aanmaken van een git repo is idd een paar minuten werk, ervoor zorgen dat onze projecten zo ingericht zijn dat we ook optimaal gebruik van git kunnen maken daarentegen is heel veel werk
We hebben zelfs hybride VB6 / .NET applicaties.
Maar het grootste probleem zijn dus die libraries die overal en nergens gebruikt worden. We hebben dus een dependency hell die we eerst moeten oplossen (vandaar dat ik intern NuGet wil gaan gebruiken). Daarnaast moeten de projecten netjes in boomstructuren worden ingericht, zodat we ze ook netjes in git kunnen onderbrengen. Zodat we daarna ook duidelijke commits voor project X hebben.
Ask yourself if you are happy and then you cease to be.
Dan snap ik, maar het blijft gewoon zo dat je dit een keer moet gaan doen. Het blijven vooruitschuiven is gewoon meer technische schuld opbouwen. Vandaar vind ik het een slap excuus. Wees dan eerlijk en zeg gewoon dat het je als bedrijf niet boeit dat je aan 't prutsen bent
Jullie gebruiken geen tool voor je dependencies? Holy crap. Dat je dat volhoudt!
Exact!
[ Voor 47% gewijzigd door Hydra op 14-02-2017 15:10 ]
https://niels.nu
Er zijn bedrijven genoeg die een product in zo'n structuur hebben zitten en daar blijkbaar nog mee kunnen werken ook. Zelfs Windows zelf zit in één gigantische repository waarvan de dependencies blijkbaar (nog) niet duidelijk te scheiden zijn. Mooi artikel daarover hier.:
[...]
Dan snap ik, maar het blijft gewoon zo dat je dit een keer moet gaan doen. Het blijven vooruitschuiven is gewoon meer technische schuld opbouwen. Vandaar vind ik het een slap excuus. Wees dan eerlijk en zeg gewoon dat het je als bedrijf niet boeit dat je aan 't prutsen bent
Microsoft is dan blijkbaar ook maar aan het prutsen volgens jou?
Beslissingen, zeker die met bedrijfs-economische impact worden nu eenmaal niet altijd alleen maar op basis van techniek genomen.
Dat gezegd hebbende: ik zou ook een traject in gang zetten om eens te kijken hoe je hier nu verder mee wilt gaan.
Hoewel ik het theoretisch gezien met je eens ben, is de praktijk helaas wat minder rooskleurig.:
[...]
Dan snap ik, maar het blijft gewoon zo dat je dit een keer moet gaan doen. Het blijven vooruitschuiven is gewoon meer technische schuld opbouwen. Vandaar vind ik het een slap excuus. Wees dan eerlijk en zeg gewoon dat het je als bedrijf niet boeit dat je aan 't prutsen bent
Alles overharken naar git in 1 keer is niet te doen. Dan gaat er zoveel kapot dat wil je niet weten.
Een jaartje of 8 geleden heb ik zoiets dergelijks geprobeerd met Team Foundation Server. Dit leidde toen tot zoveel ellende dat we noodgedwongen terug moesten migreren naar SourceSafe. En sindsdien is het een moeilijk onderwerp.
En eerlijk is eerlijk, veel collega's boeit het echt niet. Die willen er zelf dan ook weinig tijd aan kwijt zijn.
Visual Studio stelt je in staat om dit heel lang vol te houden met project references. Je voegt simpelweg een bestaand project toe aan je solution (ook al staat dit project helemaal ergens anders op jouw schijf) en voegt daarna een directe reference toe aan deze project node. Bij het builden wordt de boel dan automatisch gecompileerd en meegenomen.
Met andere woorden, Visual Studio maakt het je heel makkelijk om te prutsen
Anyways, omdat de vorige migratie naar TFS een enorme afgang was, lijkt het mij veel verstandiger om dit in kleine stappen aan te pakken.
Mijn insteek is dan ook om eerst te beginnen met het gebruiken van NuGet en daarna de projecten stapsgewijs te ordenen, zodat ze daarna wel stuk voor stuk naar git kunnen. Eerst afsplitsen en dan verhuizen dus.
Ask yourself if you are happy and then you cease to be.
Branchespecifieke software die bij aardig wat klanten in Nederland draait waar ze hun volledige administratie en bedrijfsprocessen mee ondersteunen. In grote lijnen software waar je orders intikt, voorraden in bijhoudt, facturatie mee doet, volledige boekhouding inzit, koppelingen met een hele reeks externe leveranciers, rapportages enzovoorts.
De eerste versie van de software was ooit een DOS pakket
Daarna kwam de eerste Windows versie in VB6. En ik werk vooral aan de derde generatie die volledig in .NET geschreven is.Maar de vorige versie heeft dus ook al wat .NET modules die via interop forms worden getoond
Alles om te voorkomen dat je nieuwe VB6 code moet schrijven
[ Voor 9% gewijzigd door Lethalis op 14-02-2017 16:23 ]
Ask yourself if you are happy and then you cease to be.
Programmer's Drinking Song: 99 little bugs in the code, 99 bugs in the code, Fix one bug, compile it again, 100 little bugs in the code. (go to start if bugs>0)
Ik denk ook dat het gebruiken van git voor het Linux kernel project mensen vertrouwen gaf. Zelf zie ik dat immers ook zo.
"Als een gigantisch project als de Linux kernel met git beheerd kan worden, dan moet het ook lukken voor onze eigen code"
Natuurlijk loop je dan tegen allerlei beperkingen van de Microsoft tools aan, zoals de manier waarop csproj en vbproj bestanden werken, waardoor je bij een merge pattern de hele dag niks anders aan het doen bent dan projectbestanden mergen Maar ja, daar kan git niks aan doen.
Ik heb samen - met veel andere developers - online veel gezeurd hierover bij Microsoft en ze bouwen gelukkig wildcard support in. MSBuild ondersteunde dit al langer, maar Visual Studio helaas niet. Dat .NET Core weer msbuild gaat gebruiken is voor ons indirect een zegen, omdat de tooling eindelijk een beetje aandacht krijgt.
Het liefste had ik gezien dat ze zoiets als Gradle zouden gaan gebruiken met een DSL, maar XML is altijd nog beter dan project.json voor het beschrijven van een project (kun je tenminste commentaar er in opnemen etc).
Ik bedoel, hoe moeilijk kan het zijn om gewoon met een build script te werken. Maar ja. Bij Java doen mensen niks liever dan XML laten verdwijnen en Microsoft brengt het terug. [/rant]
Wat dat betreft kan ik helaas ook niks anders concluderen dan dat Microsoft aan het prutsen is.
"Als een gigantisch project als de Linux kernel met git beheerd kan worden, dan moet het ook lukken voor onze eigen code"
Natuurlijk loop je dan tegen allerlei beperkingen van de Microsoft tools aan, zoals de manier waarop csproj en vbproj bestanden werken, waardoor je bij een merge pattern de hele dag niks anders aan het doen bent dan projectbestanden mergen
Maar ja, daar kan git niks aan doen.Ik heb samen - met veel andere developers - online veel gezeurd hierover bij Microsoft en ze bouwen gelukkig wildcard support in. MSBuild ondersteunde dit al langer, maar Visual Studio helaas niet. Dat .NET Core weer msbuild gaat gebruiken is voor ons indirect een zegen, omdat de tooling eindelijk een beetje aandacht krijgt.
Het liefste had ik gezien dat ze zoiets als Gradle zouden gaan gebruiken met een DSL, maar XML is altijd nog beter dan project.json voor het beschrijven van een project (kun je tenminste commentaar er in opnemen etc).
Ik bedoel, hoe moeilijk kan het zijn om gewoon met een build script te werken. Maar ja. Bij Java doen mensen niks liever dan XML laten verdwijnen en Microsoft brengt het terug. [/rant]
Wat dat betreft kan ik helaas ook niks anders concluderen dan dat Microsoft aan het prutsen is.
Ask yourself if you are happy and then you cease to be.
Gelukkig hebben we dat in Javaland al een jaar of 10 opgelost; niemand checkt IDE specieke meuk in:
Natuurlijk loop je dan tegen allerlei beperkingen van de Microsoft tools aan, zoals de manier waarop csproj en vbproj bestanden werken, waardoor je bij een merge pattern de hele dag niks anders aan het doen bent dan projectbestanden mergen
https://niels.nu
Nee, maar .csproj kun je simpelweg niet excluden omdat het geen tijdelijk of IDE-specifiek bestand is. Het bevat zeg maar de properties van een specifiek project, zoals references en andere instellingen. 1 van de nadelen is dat ze dus bijvoorbeeld bevatten "dit project is afhankelijk van library X versie Y". Op het moment dat je een nieuwe versie Z wilt gebruiken, verandert dus de inhoud van de csproj. En, om het leuk te maken, alle transitive dependencies worden ook expliciet opgenomen.
Dat, in combinatie met splitsen (Nuget packages, project references) maakt dat die files relatief vaak kunnen veranderen en dus gevoeliger zijn voor merge conflicten. MS heeft dat ook al lang geleden onderkent en probeert dat met .NET Core recht te trekken. Het is inderdaad erg tijdrovend namelijk
Dat, in combinatie met splitsen (Nuget packages, project references) maakt dat die files relatief vaak kunnen veranderen en dus gevoeliger zijn voor merge conflicten. MS heeft dat ook al lang geleden onderkent en probeert dat met .NET Core recht te trekken. Het is inderdaad erg tijdrovend namelijk
Programmer's Drinking Song: 99 little bugs in the code, 99 bugs in the code, Fix one bug, compile it again, 100 little bugs in the code. (go to start if bugs>0)
Het grote verschil is dat je bij Java - zolang je een build tool gebruikt als Maven of Gradle - altijd de IDE specifieke bestanden kunt genereren.
Visual Studio en msbuild hebben echter al die project en solution files gewoon nodig om te werken. Als je die niet in source control opneemt, dan wens ik je veel succes bij het openen van een solution die tig dependencies heeft en uit meerdere projecten bestaat.
Of om het in C++ termen te zeggen: er is geen scheiding tussen de makefile en de IDE project files. Het is alles in 1.
Het is alleen jammer dat ze dan eerst iets verzinnen dat nergens op slaat en door het bestandsformaat erg beperkt wordt (project.json), om vervolgens weer terug te gaan naar msbuild dat qua featureset het niet eens haalt bij wat in Java land Maven is.:
Dat, in combinatie met splitsen (Nuget packages, project references) maakt dat die files relatief vaak kunnen veranderen en dus gevoeliger zijn voor merge conflicten. MS heeft dat ook al lang geleden onderkent en probeert dat met .NET Core recht te trekken. Het is inderdaad erg tijdrovend namelijk
Terwijl ze daar vaak al DSL's gebruiken, zoals bij Gradle, omdat XML omslachtig is en onhandig is om te mergen.
Zoals ik het zie, zou Microsoft met een nieuw formaat moeten komen waarin je een DSL kunt gebruiken.
Al is het friggin' VB for all I care:
code:
1
2
3
4
5
6
7
| ProjectName = "Test"
AddReference("System.Drawing")
Target = "dll"
PublishTask {
Target = "ftp://123.123.123.123/www/test"
} |
Zoiets. Waarom kan de hele wereld dit wel, maar Microsoft niet? XML leest rot, merge't rot, is gewoon rot voor dit soort taken. En JSON is helemaal belachelijk. Je wil gewoon commentaar kunnen opnemen in de build files, andere build files kunnen includen, plugins kunnen gebruiken, enzovoorts.
[ Voor 56% gewijzigd door Lethalis op 15-02-2017 13:38 ]
Ask yourself if you are happy and then you cease to be.
Mwa. Het grote voordeel van Gradle is dat je complete build scripts in je build.gradle kan programmeren. Het grote nadeel van Gradle is dat mensen complete build scripts in hun build.gradle programmeren.
In teamverband heb ik dan ook liever Maven
https://niels.nu
Maar je vergeet nog het leukste en dat is - zolang er geen wildcard support is - dat elk bestandje er in staat::
Nee, maar .csproj kun je simpelweg niet excluden omdat het geen tijdelijk of IDE-specifiek bestand is. Het bevat zeg maar de properties van een specifiek project, zoals references en andere instellingen. 1 van de nadelen is dat ze dus bijvoorbeeld bevatten "dit project is afhankelijk van library X versie Y". Op het moment dat je een nieuwe versie Z wilt gebruiken, verandert dus de inhoud van de csproj. En, om het leuk te maken, alle transitive dependencies worden ook expliciet opgenomen.
Dat, in combinatie met splitsen (Nuget packages, project references) maakt dat die files relatief vaak kunnen veranderen en dus gevoeliger zijn voor merge conflicten. MS heeft dat ook al lang geleden onderkent en probeert dat met .NET Core recht te trekken. Het is inderdaad erg tijdrovend namelijk
http://haacked.com/archiv...6/csproj-merge-conflicts/
Het formaat an sich zorgt ervoor dat je merge conflicts krijgt en het mergen ook nog eens mislukt.
Zodra jij alleen maar HelloWorld.cs toevoegt aan een project en een collega tegelijkertijd Test.cs, dan is het al klaar. Dat kan zich de gemiddelde Java dev niet eens voorstellen
Die is gewend dat alles wat in zijn src map staat, simpelweg bij het project hoort. Dus wanneer meerdere mensen classes toevoegen, is er niks aan de hand.Daar is wel iets voor te zeggen.:
[...]
Mwa. Het grote voordeel van Gradle is dat je complete build scripts in je build.gradle kan programmeren. Het grote nadeel van Gradle is dat mensen complete build scripts in hun build.gradle programmeren.
In teamverband heb ik dan ook liever Maven
Maar dan nog is een Maven bestand een stuk beter te behappen dan een csproj bestand. Je kan gewoon netjes alles zelf documenteren, parameters opnemen voor versies van libraries die bij elkaar horen (bijv. de versie van Spring), enzovoorts.
En omdat je niet elk class bestand apart hoeft te includen, kom je er ook veel minder vaak mee in aanraking.
Dit staat bijvoorbeeld in de csproj van een testproject van mij:
code:
1
2
3
4
5
6
7
8
9
10
| <ItemGroup>
<Compile Include="Models\AuthenticationLogon.cs" />
<Compile Include="Models\AuthenticationRequest.cs" />
<Compile Include="Core\WebTokenFunctions.cs" />
<Compile Include="CustomBootstrapper.cs" />
<Compile Include="Extensions\NancyModuleExtensions.cs" />
<Compile Include="Modules\AuthModule.cs" />
<Compile Include="Modules\HalloModule.cs" />
<Compile Include="Modules\HalloSecureModule.cs" />
... |
Elke class wordt vernoemd. Dat is echt killing voor het aantal merges.
MSBuild kan dit:
code:
1
2
3
| <ItemGroup>
<Compile Include="Models\*.cs" />
... |
Maar als je dat dan met Visual Studio opent, dan maakt hij doodleuk al die entries weer automatisch aan
Gotta love it.
Visual Studio 2017 zou dit nu eindelijk niet meer doen. Ik ben benieuwd...
[ Voor 36% gewijzigd door Lethalis op 15-02-2017 14:01 ]
Ask yourself if you are happy and then you cease to be.
Wel mooi dat een git build gelijk een berg unittests draait, duurt alleen wel een tijdje voordat je pakketje eindelijk is compleet is
Hoe bedoel je? Falende tests breken bij ons altijd de build. Dan is de software stuk nl.:
Wel mooi dat een git build gelijk een berg unittests draait, duurt alleen wel een tijdje voordat je pakketje eindelijk is compleet is
https://niels.nu
een dpkg-buildpackage van git duurt een aardige tijd, compileren valt wel mee, runnen van alle tig tests een behoorlijke tijd, maar goed allemaal voor het goede doel
Python zit sinds afgelopen vrijdag ook op GitHub
Research is to see what everybody else has seen, and to think what nobody else has thought - Albert Szent-Györgyi
Ja ik geloof er ook niet in dat mensen gaan overstappen. Sowieso is dat niet te doen wanneer je met grote projecten werkt en een grote eigen verzameling van libraries hebt gemaakt.
Ik zit net zo vast aan .NET als jij aan Java waarschijnlijk. En zolang de .Net standard niet volwassen is, kan ik niet eens .NET Core gebruiken.
C# an sich is wel goed, maar begint ook gedateerd te worden wanneer je de taal met nieuwere talen als Kotlin, Scala of Swift gaat vergelijken.
Hoe hosten jullie eigenlijk de bare git repositories? Bij ons moet de code sowieso on premises blijven, dus online diensten vallen af.
Tot nu toe is gogs.io het leukste dat ik getest heb, maar misschien is er wel iets beters
[ Voor 3% gewijzigd door Lethalis op 16-02-2017 18:41 ]
Ask yourself if you are happy and then you cease to be.
De laatste keer dat ik gitlab heb getest, vond ik het een heel zwaar en traag pakket (qua memory usage etc).
Ook vond ik de backup en restore procedures ingewikkeld.
Ik zou bijna gewoon een Linux VM met alleen SSH gebruiken, maar iets zegt me dat mijn collega's dan gaan piepen dat het te ingewikkeld is
Ask yourself if you are happy and then you cease to be.
Tegenwoordig met Gitlab Omnibus is het uitrollen op een kale Linux VM wel heel eenvoudig en betrouwbaar. Maar als je alleen een git repo zoekt is iets als gitolite ook al voldoende natuurlijk. Gitlab draait bij ons (10 users) in een VM met 6GB RAM dus ja echt licht is het niet.:
[...]
De laatste keer dat ik gitlab heb getest, vond ik het een heel zwaar en traag pakket (qua memory usage etc).
Ook vond ik de backup en restore procedures ingewikkeld.
Ik zou bijna gewoon een Linux VM met alleen SSH gebruiken, maar iets zegt me dat mijn collega's dan gaan piepen dat het te ingewikkeld is
:strip_icc():strip_exif()/u/206968/325134.jpg?f=community)
Bweg hebben die gitlab ruby jongens iets met go in elkaar proberen te klussen (gitlab-workhorse) maar die meuk compileert dus niet 
*zucht* geen zin om me te gaan verdiepen in go z'n package dependency management toolie. Dan maar de backup restoren en be done with it.
*zucht* geen zin om me te gaan verdiepen in go z'n package dependency management toolie. Dan maar de backup restoren en be done with it.
:strip_icc():strip_exif()/u/36378/crop5a3f931ecfec0_cropped.jpeg?f=community)
Verwijderd
Hi guys,
I'm developer of Fork.
I'm from Prague and I don't speak Dutch. So I used Google Translate and understood that you guys miss a possibility to see a diff between two commits.
Fork does have that feature already for about a month or so. To diff two revisions just hold the CMD key and select the commits you want to compare.
I'm open to requests, so if you miss any other feature in Fork feel free to contact me directly by email (or use the feedback button on the toolbar).
Regards,
Dan
P.S. BTW, it was really tricky to post that, because the whole Czech is banned on that website. I tried Tor, but it's blocked too. I sent an email to support, but they didn't answer.
I'm developer of Fork.
I'm from Prague and I don't speak Dutch. So I used Google Translate and understood that you guys miss a possibility to see a diff between two commits
.Fork does have that feature already for about a month or so. To diff two revisions just hold the CMD key and select the commits you want to compare.
I'm open to requests, so if you miss any other feature in Fork feel free to contact me directly by email (or use the feedback button on the toolbar).
Regards,
Dan
P.S. BTW, it was really tricky to post that, because the whole Czech is banned on that website. I tried Tor, but it's blocked too. I sent an email to support, but they didn't answer.
[ Voor 14% gewijzigd door Verwijderd op 22-02-2017 18:56 ]
Heh, cool
Welcome! If you have any questions feel free to ask; we're happy to translate for you.
https://niels.nu
Thanks Dan. I updated the topic startpost.:
... and understood that you guys miss a possibility to see a diff between two commits
Fork does have that feature already for about a month or so. To diff two revisions just hold the CMD key and select the commits you want to compare.
Een wappie is iemand die gevallen is voor de (jarenlange) Russische desinformatiecampagnes.
Wantrouwen en confirmation bias doen de rest.