Git er ikke versionskontrol

Vi har haft en lille debat på den interne FreeBSD udviklerliste, der var nogen der gerne ville have skiftet SVN ud med Git fordi det er "meget smartere".

Det kom der, igen, en længere debat ud af.

Det forbavser mig til stadighed at de fleste mennesker omtaler Git som "versionskontrol", for det er det vitterligt ikke - det er noget meget smartere og mere moderne.

Et klassisk versionskontrolværktøj giver (mindst) følgende garantier:

En definitiv tidslinie - Der er aldrig tvivl om hvorvidt ændring X er med eller ej, ejheller om den kom med før eller efter ændring Y.

Et fortløbende versionsnummer - Muligvis i flere niveauer, men altid til stadighed voksende.

Historisk stabilitet - ændringer der er lavet bliver ved med at være lavet. Ombestemmer man sig kræver det en ændring mere.

Hvis man skriver kontrakt på software for over 1 million kroner og ikke insisterer på at der bruges et versionkontrolværktøj der giver disse garantier er man i bedste fald kun en klaptorsk.

For Git var Linus' designkriterier at gøre det stik modsatte.[1]

Dermed kan vi konstatere at Linus er en klaptorsk når det kommer til versionskontrol, men det er ikke er nogen nyhed.

I modsætning til alle os andre stakler har Linus i over 25 år levet i en drømmeverden hvor de ovenstående tre garantier gives af ham, personligt og der er ingenting andre, hverken chefer eller advokater, kan gøre ved det.

Som Mel Brooks har observeret: "It's Good To Be The King"

Det værktøj som Linus havde brug for var derfor ikke versionskontrol, men noget groupware.

Man manglede et værktøj der tillod en uvasket menneskemængde at samarbejde om et katalogtræ, på tværs af ideer, sprog, projekter, firmaer og ikke mindst evner, således at de alle hver for sig kan have og arbejde på deres egen definitive version af Linux-kernen og således at de kan udveksle ændringsforslag nemt, bekvemt og automatisk med hinanden og med ham.

Derfor er det f.eks utroligt klogt at der absolut ingen semantisk mening er er i Gits "versionsnumre". De er anonyme tilfældigt udseende nonces der ikke kan starte en arvefølgekrig om hvorvidt Alices version 1.2343 på en eller anden måde har forrang for Bobs version 1.2344.

Man kan dog sagtens bruge Git som en slags versionskontrolværktøj, ved at tilføje det ting der bevidst blev udeladt:

1) Udpej det definitive Git træs placering og beslut hvem tager backup af det. Se også: Github.

2) Udpej den "Linus" der har magten til at bestemme hvad den "rigtige" rækkefølge af ændringer er og jobbet med at klaske et nyt fortløbende versionsnummer på i ny og næ.

For så vidt den sidste garanti kommer man dog lidt til kort og må nøjes med:

3) Kryds fingre for at ingen af dem der har push rettigheder til det centrale git repo dummer sig.

Men det er godt nok i 90% eller måske ligefrem 99% af alle softwareprojekter, ikke mindst indenfor FOSS.

Men hvis man har brug for rigtig versionkontrol er det smartere at automatisere opgaven med et rigtigt versionskontrolsystem.

Og det forhindrer ikke på nogen måde at man bruge Git til det det er designet til og som det er rigtig godt til, nemlig gruppearbejde.

phk

[1] Se f.eks denne Google TechTalk

Poul-Henning Kamps billede
Poul-Henning er selvstændig systemprogrammør, kernekoder, Varnish-forfatter, data-arkæolog og brokkehoved uden særlig portefølje.

Kommentarer (96)

Esben Nielsen

Ud over en masse følelsesladede rants mod Linus Torvalds kan jeg se ét teknisk argument:

Der er ingen ordning på Gits "versionsnumre".

Nej, men de udpeget indholdet af en version mange gange mere entydigt end et SVN versionsnummer:

Gits hashnøgler er en (godt nok svag) kryptografisk hash over indholdet og historien i source-træet. Så giver du mig hashen for en version, og jeg kan finde den i mit træ på min PC, er der ekstrem god chance for, at det er præcis den samme version, vi taler om.

Med SVN eller andre centrale versionsstyringssystemer, er der en risiko for at det centrale træ har været ændret ved et uheld: dårlig disk og backup indeholdte ikke lige de nyeste versioner. Eller admin har fundet på at ændre eller fjerne filer fra selve SVN databasen.
Så når, du checker version 49153 ud af en SVN database kan den være forskellig fra dag til dag!
Indholdet af en hash i Git kan kun have ændret sig, hvis nogen laver et decideret angreb på SHA1-checksummen - hvilket er meget svært (men dog muligt).

På mit arbejde er vi skiftet fra SVN til Git for et års tid tilbage. Der er ingen, som ser sig tilbage og savner SVN's versionsnumre nu.

Med hashes har vi meget bedre styr på versionerne:
Alle byg er påstemplet et hash, og når vi laver et "release" arkiverer vi simpelthen en git-klon, hvori det hash forekommer.

Morten Mathiasen

Kære Poul-Henning.

Jeg ved ikke rigtigt på hvilket grundlag, du bygger din artikel, men det er vist ikke fra den praktiske virkelighed, hvor software frigives til kunder i gentagne releases.

Du har ikke ret i at kunder efterspørger et versionnummer. Kunder efterspørger udelukkende hvilke funktionaliteter, der tilbydes i deres software.

Du har ret i at udviklerne til brug for fejlretning og videreudvikling har behov for at vide præcist hvilken software, der er inkluderet i kundernes releases. Git commit id fortæller dette helt præcist - nemmere end noget andet versionskontrolsystem.

Om man markedsføringmæssigt vil beskrive software releases med versionsnummer, produktnavne eller noget helt andet har intet at gøre med om man bruger Git eller et andet versionskontrolsystem.

Casper Bang

Det er jo en gammel debat. Selv om dine argumenter er fine nok, så synes du at udelade at man jo sagtens kan bruge Git som traditionel versionskontrol - selv om Linus ikke oprindeligt havde dette for øje. Det kræver bare at man 1) udnævner ét master repo - det har de fleste organisationer alligevel 2) udnævner en master/stable/release/integration branch - det er der ligeledes mange der kører med og 3) benytter git commit nr. på sin master branch (git rev-list HEAD --count). Dette fungerer f.eks. fantastisk til Android udvikling, hvor kravet fra Google til versionCode netop et en fortløbende integer.

Som fan af semantisk versionering (og branches og tags), benytter jeg mig dog af ofte af tags til [major].[minor] og tæller [path] som antallet af commits siden seneste tag (git rev-list --tags --no-walk --max-count=1). Dette anser jeg dog som "marketingsversionsnavn" i dén forstand at her gælder det kommunikation til mennesker omkring bagudkompatibilitet osv.

Where there's a will there's a way.

Poul-Henning Kamp Blogger

så synes du at udelade at man jo sagtens kan bruge Git som traditionel versionskontrol

Hvilken del af "Man kan dog sagtens bruge Git som en slags versionskontrolværktøj" var det du ikke læste ?

Git commit id fortæller dette helt præcist - nemmere end noget andet versionskontrolsystem.

Det er hverken nemmere eller sværere end med noget andet VCS.

Oftest er det dog noget nemmere for kunden at sige "1.3434" end "213939a3cf031" i telefonen.

Men det forudsætter at du kan genskabe den commit id når kunden ringer.

Det giver Git ikke nogen garanti for, mens et rigtigt VCS garanterer uforanderligheden af ethvert commit.

Det er fint og klogt af Git at bruge en kryptografisk hash til konsistenscheck, noget i den stil bør alle distribuerede værktøjer have, (Valget af SHA1 ? - Ikke så smart.)

Men det sikrer dig kun imod disk og transmissionsfejl, det sikrer dig ikke imod folk der dummer sig med selve git(1) kommandoen. (Se også: punkt 3 nederst i bloggen.)

Alle byg er påstemplet et hash, og når vi laver et "release" arkiverer vi simpelthen en git-klon, hvori det hash forekommer.

Præcis som jeg skrev: Det er I nødt til at gøre, fordi Git ikke giver en garanti for at ting forbliver de samme i al evighed. (Se også: punkt 1 nederst i bloggen.)

Det er sikkert, som jeg også skrev en brugbar metode for jeres formodentlig relativt lille projekt, men når dit Git træ vokser vel op i gigabytes og terabytes er det pludselig ikke så sjovt mere. (Se også: https://www.version2.dk/blog/derfor-sutter-windows-1073005)

Du har ikke ret i at kunder efterspørger et versionnummer. Kunder efterspørger udelukkende hvilke funktionaliteter, der tilbydes i deres software.

Det afhænger 100% af hvem dine kunder er.

Hvis vi taler om en webshop til en blomsterbutik: Helt klart enig.

Hvis vi taler om Rigspolitiet og POLSAG: Du har desværre ret.

Hvis vi taler om indlejret software i fly, våben, radar og den slags: Helt klart uenig, her er sporbarhed og reproducerbarhed et nærmest ultimativt krav.

Ud over en masse følelsesladede rants mod Linus Torvalds

Der er absolut intet følelseladet i det her, Linus må som alle andre hænge i det reb han selv slynger over galgen.

Hvis du ser den video jeg linkede til helt til ende hvor Googles medarbejdere begynder at stille vantro spørgsmål, vil du se hvor langt hans situation er fra alle andres.

Michael Zedeler

Uforanderlig historik:

receive.denyNonFastForwards
receive.denyDeletes

Fortløbende nummerering af commits:

Løses med en server side hook. Hvis du kan få den til at fylde mere end tre linjer, er der noget galt.

Var der andet?

Esben Nielsen

Det er sikkert, som jeg også skrev en brugbar metode for jeres formodentlig relativt lille projekt, men når dit Git træ vokser vel op i gigabytes og terabytes er det pludselig ikke så sjovt mere. (Se også: https://www.version2.dk/blog/derfor-sutter-windows-1073005)

Tjaa, et lille projekt med over 5 milioner linier kode med history konverteret fra SVN konverteret fra CVS 15 år tilbage i tiden kan Git sagtens håndtere.

Og som du selv påpeger i dit eget blogindlæg burde store projekter deles op i mindre enheder af helt andre årsager. Det har vi faktisk allerede gjort..

Alle byg er påstemplet et hash, og når vi laver et "release" arkiverer vi simpelthen en git-klon, hvori det hash forekommer.

Præcis som jeg skrev: Det er I nødt til at gøre, fordi Git ikke giver en garanti for at ting forbliver de samme i al evighed. (Se også: punkt 1 nederst i bloggen.)

Da vi brugte SVN gjorde vi det samme - dog uden historik - da der ikke er nogen garenti for at SVN serveren kører (og forbliver den samme) om lad os sige 5 eller 10 år, hvis nogen skal lave en rettelse til noget vi har leveret til en kunde.

Michael Zedeler

F.eks git commit --reset-author, --author, --amend osv.

Det får du ikke lov til at dele med andre, hvis man bruger de indstillinger, jeg anførte ovenfor.

Hvis man er ekstra paranoid, kan man også bruge signerede commits.

For mit vedkommende er git i høj grad revisionskontrol. Det er bare revisionskontrol for udviklere - ikke for papirnussere (læs: revisorer).

Jacob Larsen

Kryds fingre for at ingen af dem der har push rettigheder til det centrale git repo dummer sig.

Det er reelt force push rettigheder det drejer sig om. Og hvis projektet skal køre som du beskriver så kan man bare slå dem fra.

Esben Nielsen
Torben Jensen

Så svært er det faktisk heller ikke.

Det er nemmere for en virksomhed at forholde sig til at version 1,2,3 fungerede super, 4,5 havde en øv, 6 fixede øv'en, 9 var øv'en tilbage. Osv.

Det er meget nemmere for udenforstående at tracke på kvaliteten af det leverede hvis de kan forholde sig til noget liniært.

Vi kan altid diskutere værdien, men det ændrer ikke på at det er nemmere at forholde sig til at 9 kom efter 6 hvis man ikke står med en git graph.

Sune Marcher

Vi kan altid diskutere værdien, men det ændrer ikke på at det er nemmere at forholde sig til at 9 kom efter 6 hvis man ikke står med en git graph.


Det har du ret i.

Men hvis man bruger signed tags med semantisk versionsnummer til leverancer, hvor er problemet så?

Findes der sådan helt specifikke (og, i kontekst, ekstremt tekniske krav) om at sourcekode skal være i et VCS der kun anvender fortløbende integers som commit-id, og at systemet ikke må indeholde fx commit-amend, selvom man kan sikre sig mod det i praksis (no-force repo + krav om signed commits)?

Michael Zedeler

For mit vedkommende er git i høj grad revisionskontrol. Det er bare revisionskontrol for udviklere - ikke for papirnussere (læs: revisorer).

Præcis som jeg skrev: Git er Groupware.

Lige her synes jeg egentlig ikke bare det bliver en kamp om ligegyldige ord. I alle praktiske henseender giver git mig som udvikler præcis det, jeg beskriver som revisionskontrol, nemlig kontrol med forskellige revisioner af noget kode, jeg arbejder på. Siden Version 2 er for udviklere og ikke revisorer, mener jeg at det er korrekt at betegne det som sådan.

Det er fint nok at du (ligesom jeg og mange andre) har opdaget at git har nogle standardindstillinger som gør at man fra et it-sikkerhedsmæssigt synspunkt ikke kan garantere at der ikke er blevet pillet i historikken. Som Jacob og jeg har pointeret, er det primært et spørgsmål om at slå force push fra. Så er den ged barberet.

Som udvikler har jeg følgende krav til revisionskontrol:
* Man kan være et hold af udviklere som arbejder på det samme system på samme tid
* Man kan spore ændringer i forbindelse med fejlsøgning og den slags
* Man kan markere bestemte revisioner med tags
* Man kan lave branches med kode som flere arbejder på samtidig

Det er lige præcis det, git løser for mig. Ikke nok med det, det er langt, langt mere effektivt end CVS og Subversion.

Anders Reinhardt Hansen

3) Kryds fingre for at ingen af dem der har push rettigheder til det centrale git repo dummer sig.

Man kan bare fjerne rettigheder til push til master/develop branch og udelukkende acceptere at kode kommer ind i disse gennem Pull Requests.

Kristian Rastrup

Findes der sådan helt specifikke (og, i kontekst, ekstremt tekniske krav) om at sourcekode skal være i et VCS der kun anvender fortløbende integers som commit-id, og at systemet ikke må indeholde fx commit-amend, selvom man kan sikre sig mod det i praksis (no-force repo + krav om signed commits)?

Vores dokumentation er ikke så præcis.
Men der skal være 100% sporbarhed fra kørende software og ned til den matchende version af den enkelte kildekodefil og tilhørende code review, dokumentation, change request, compiler setting mv. som så er skrevet med tilpas margen til at rumme mange forskellige måder at håndtere forskellige udviklingsmiljøer som MS, Java og SAP.

Jeg er ikke ekspert i Git repo konfiguration men jeg går ud fra at de settings du beskriver kan slås fra og til efter behov hvilket fjerner deres værdi i en sporbarhedskontekst.

Poul-Henning Kamp Blogger

Man kan bare fjerne rettigheder til push til master/develop branch og udelukkende acceptere at kode kommer ind i disse gennem Pull Requests.

Ja, præcis som jeg skrev, man kan godt bruge Git til versionskontrol, hvis man tilfører de funktioner der mangler via procedurer (Præcis som Linus selv gør det, tilsyneladende uden at have forstået betydningen deraf.)

Men når man kommer op i den tunge ende, er det smartere at bruge et VCS der ikke har brug for den slags "støttehjul".

Lars Skovlund

Hvis du ser den video jeg linkede til helt til ende hvor Googles medarbejdere begynder at stille vantro spørgsmål, vil du se hvor langt hans situation er fra alle andres.


Så vidt jeg husker var det dig, PHK, der sidst argumenterede imod at have hele sin kodebase i et repo? Det har Google, så jeg er lidt overrasket over at du bringer dem på bane som et fyrtårn nu. Desuden kører de DVCS (Mercurial), eller som du kalder det, "groupware". Og nej, jeg gider ikke se videoen. Hvis du vil argumentere din sag, så kan du gøre det i dit blogindlæg.

Henrik Jacobsen

Hvis vi taler om indlejret software i fly, våben, radar og den slags: Helt klart uenig, her er sporbarhed og reproducerbarhed et nærmest ultimativt krav.


Jeps.
Source til hver release tagges i git.
Ved næste release:
FAA's repræsentant bevidner at checkout af dette tag kan genbygge SW binært identisk med den der er ude i verden.
Source til den nye release tagges, diff på de 2 tags dokumenterer hvad der er ændret. Alle ændringer skal beskrives, begrundes og testes.
"Versionsnummeret" som kunder ser, vælges helt uafhængigt. Det interesserer ikke nogen ift. godkendelsen.

FAA har ikke problemer med brugen af git i dette setup.

Anders Reinhardt Hansen
Jørgen Elgaard Larsen

Jeg er ikke ekspert i Git repo konfiguration men jeg går ud fra at de settings du beskriver kan slås fra og til efter behov hvilket fjerner deres værdi i en sporbarhedskontekst.

Ja, det kan slås fra og til på samme måde som man kan pille som man lyster i et Subversion-repository: Man skal være administrator og ikke blive logget.

Det bør i sig selv ikke være tilfældet, hvis du stiller strenge krav om revisionskontrol.

Forskellen er, at med git har du en chance for, at en udvikler eller revisor ligger inde med en klon af repositoriet, som både kan bruges til kontrol og til genskabelse af din master.

Med SVN vil du bare have tabt.

Troels Liebe Bentsen

> Jeg misunder dig din ungdommelige(?) naivitet med hensyn til hvad advokater, lovgivere >og embedsmænd kan finde på at stille som krav.
>
>Nyd det!

Jeg tror vi er på stykker som ikke oplever den modstand du snakker om, jeg har de sidste par år arbejdet med virksomhedder som er underlangt tung lovgivning på den ene eller anden måde(Finans, offentlige og medicinsk) og bruger desværre en god del af min tid på at snakke med legal, compliance og audit folk som er glade for at stille krav.

Selvfølgelig er sporbarhed fra kildekode til produktion en af de krav jeg har mødt, men det er først gang jeg at jeg har de skulle have en holding til hvordan det bliver gjort.

Hvis jeg kan svare på spørgsmålet "kan du vise mig precise den kode køre i production samt hvem der har skrevet dem og hvornår" så er der ikke den store intresse ud over det. For hvorfor skulle der være en intresse for tekniske detaljer om koden ligger i SVN eller GIT eller om releasen er navngivet med en hash eller et nummer. Det er kun udviklere der gider skændes om det.

Som en lang rækker folk også har dokumenteret i tråden er det ikke noget problem at sætte git op til at kunne leve på til det krav. Hvilket også betyder vi har kunne bruge git alle de steder jeg har arbejdet de sidste par år uden at nogen haft en holding til det.

Som en afsluttende bemærkning så har jeg oftere oplevet at det er udviklere og andre på den tekniske side der stiller mærkelig krav til sig selv. Ofte er undskyldningen at man skal level op til et krav fra legal, compliance og/eller audit. Hvis man så faktisk snakker med dem der ved noget om emnet og har ansvaret er det ikke noget de har en holding til eller overhovedet intereser sig for.

Troels Liebe Bentsen

Der er ikke noget der hedder admin i git, git beskæftiger sig ikke med bruger rettigheder man kan bruge forskellige systemer over på til at håndtere det, fx. Gitolite, Github, GitLab, BitBucket, TFS, etc. og for nogen af dem kan det hele styres fra webinterface og for nogen af dem skal der være filserver adgang. Det samme gælder for SVN hvor opgaven til sikkeheder overlades til en apache plugin eller en speciel SVN server, men man kunne sådan set ligge repo'et på en delt netværks drev hvis man ikke vidste bedre.

Alexander Færøy

God pointe!

I 2008 skrev du en artikel her på Version2 med titlen "Død over CVS!"1 omkring valget af det, allerede dengang, umoderne Subversion VCS i FreeBSD projektet. Her var et af argumenterne lige netop at i skulle kunne følge det "ufravigelige krav" om at enkelte commits skulle kunne fjernes helt fra jeres historik, hvis en advokat kiggede forbi. En egenskab, som allerede dengang var noget Git gjorde langt lettere tilgængelig for udviklerne end Subversion gjorde, men hvor en administrator stadig ville kunne håndhæve og bestemme hvem, der kan lave disse omskrivninger og hvornår disse omskrivninger af historikken måtte finde sted.

Jeg har ikke set en pendant til den famøse Tetris historie i open source miljøet de efterfølgende år hvor Git blev gjort populært - ikke at de to ting er relateret. Når f.eks. Github modtager et skriv fra en advokat virker det mest til at de blåt fjerner folks repositories og kontakter dem derefter.

Heldigvis for de udviklere, der gerne vil benytte et moderne værktøj som Git er der bygget broer, som f.eks. git-svn, der lader udviklerne benytte det værktøj de foretrækker selvom virksomheden eller ens FOSS projekt benytter sig af et andet værktøj. I WebKit projektet brugte vi Subversion af den ene grund, at det var hvad Apple sagde vi skulle benytte (sikkert med mindre glæde i forrige uge2), men klart størstedelen af udviklerne brugte git-svn i deres daglige arbejde. Jeg kunne forestille mig, at det samme er gældende for FreeBSD og at man i dag afventer at mængden af folk, der benytter et værktøj som git-svn bliver større end mængden af folk, der benytter svn? :-)

I sidste ende hvis du har en kontrakt på N mio. kroner til at skrive software for må vi håbe at folk benytter værktøjer, der sikrer at ingen har direkte adgang til ens kodetræ, men at man derimod skal gå igennem et review værktøj, hvor der skal mere end en enkelt person, der nikker til din ændring, før den bliver smidt i SCM/VCS/RCS/"Groupware" træet af værktøjet selv - dette er da heldigvis også langsomt på vej frem i open source miljøet :-)

En af de fedeste ting ved Git er lige netop at man, i rigtig mange situationer, kan implementere den model, der passer bedst til ens arbejde - i modsætning til CVS/Subversion. Dette har helt sikkert også skræmt mange væk første gang de prøvede at benytte værktøjet eftersom der ikke er en "sådan skal du bruge Git"-manual.

Esben Nielsen

Det er fint nok at du (ligesom jeg og mange andre) har opdaget at git har nogle standardindstillinger som gør at man fra et it-sikkerhedsmæssigt synspunkt ikke kan garantere at der ikke er blevet pillet i historikken. Som Jacob og jeg har pointeret, er det primært et spørgsmål om at slå force push fra. Så er den ged barberet.

Det er ikke rigtigt: Hvis du lader være med at referere til tags eller branches men hashes kan folk ikke pille uden at lave et angreb på SHA1, hvor en admin i SVN blot direkte kan gå ind og ændre en revision. Så man kan i Git ikke på nogen måde (uden at bryde SHA1) pille i historikken - heller ikke som admin.

Men man kan sætte en branch til at peget på noget nyt. Intentionen med at forbyde push force, er at den pegepind ikke kan hoppe tilbage i historikken og på den måde glemme nogle commits.

Men så er det ikke IT-sikkerhedsmæssigt nok at slå push force fra: Man kan jo blot nedlægge en branch og oprette den igen med et andet HEAD og dermed lave en push force ad bagvejen. Så man skal også slå muligheden for at slette branches fra for at være sikker på at alle versioner ligger på serveren.

Brian Vraamark

Start med at læse følgende: http://www.bitsnbites.eu/a-tidy-linear-git-history/

Vi kan vel alle godt være enige i at der ikke er en lineær historik i Git? Når nogle siger at man "bare" kan bruge hash som dokumentation for en given release er det ikke rigtigt. En senere merge med en anden branch, vil "ændre på fortiden". Der kan komme commits med ind som placere sig tidsmæssig før den hash man brugte til markering af en release (se ovenstående link).

Ja man kan komme uden om en masse problemer, men det kræver en masse manuelt arbejde med et hav af Git kommandoer (herunder rebase). Det beskrives i den artikel jeg linker til, men det kræver at alle i teamet følger samme regler. Der skal som regel kun en idiot til at ødelægge det hele.

At der i Git er så mange forskellige måder at gøre det på og at der samtidig findes en nærmest uendelig strøm af hjælpe værktøjer til Git (fx Git Easy), er for mig tegn på et dårligt design.

I SVN skal den enkelte udvikler "bare" være brugere. Man kommer langt med update, commit og merge. I Git skal alle mere eller mindre være Git admin. Der er ikke meget KISS over Git.

Alexander Færøy

Ja man kan komme uden om en masse problemer, men det kræver en masse manuelt arbejde med et hav af Git kommandoer (herunder rebase). Det beskrives i den artikel jeg linker til, men det kræver at alle i teamet følger samme regler. Der skal som regel kun en idiot til at ødelægge det hele.

Du kan tvinge Git til ikke at acceptere merge-commits og dermed tvinge "lineær historik" igennem (dog ikke ift. tid, hvilket også er ligemeget), så er problemet med den ene idiot løst, personen får en fejl og bliver nød til at lave et rebase af sine ændringer før de kan komme videre.

På Github er det her et flueben væk og derefter behøver du ikke tænke mere over det problem.

Esben Skov Pedersen

Det er faktuelt forkert at der er ikke er en fastdefineret timeline i git. Ja for urelaterede commits, men git er bygget op ved at hvert commit gemmer referencer til parents. Der kan være op til 2 parents. Det betyder at commits kan følges som som en slags linked list. I praksis vil det derfor være muligt at se hvilket commit der kommer først.

Derfor er det uheldigt at der bliver sagt som at der ikke er noget tracebility. Det vidner desværre om at dette simple faktum ikke er forstået og desværre vil den forkerte konklusion der kommes frem til desværre nok blive brugt til at træffe nogle uhensigtsmæssige beslutninger fordi et stort navn inden for IT siger det.

Få venligst styr på fakta!

Sune Marcher

Jeg gætter på med den forskel at i Git skal man være admin i Git og med SVN skal man være admin på filserveren.


Du kan lave alt det hærværk du vil i dit eget repository - men hvis der anvendes et centralt repository (GitHub, BitBucket, eller en af de forskellige on-premise løsninger) er der naturligvis en masse management muligheder.

Ja, der er også mulighed for at slå force-commit mulighed til igen, men hvis du ikke stoler på dine admins er du under alle omstændigheder fucked - og du vil være mere fucked med svn end med git.

Chris Bagge

FAA's repræsentant bevidner at checkout af dette tag kan genbygge SW binært identisk med den der er ude i verden.
Source til den nye release tagges, diff på de 2 tags dokumenterer hvad der er ændret. Alle ændringer skal beskrives, begrundes og testes.
"Versionsnummeret" som kunder ser, vælges helt uafhængigt. Det interesserer ikke nogen ift. godkendelsen.

FAA har ikke problemer med brugen af git i dette setup.


Det du har her er at du i praksis indfører en helt manuel versionsstyrings process oven på git. Det er den der rent juridisk er din "versionsstyring". Hvad du så laver nede i maskinrummet, det interesserer auditor sig (forhåbentligt) ikke for.

Bemærkninger om at hvis man 'bare' sørger for at sætte visse options er noget der i den grad kan få en auditor til at spidse ører. Det næste spørgsmål er så, hvordan sikrer i jer så at man altid 'bare' gør det rigtige? Hvordan har i sikret jer at man ikke 'bare' gør noget man ikke må?

Med en snart livslang erfaring (er begyndt at udskyde folkepensionen) skal man ikke forsøge at udkæmpe kampe med en auditor. Det er spild af tid. De er ikke specialister på dit fagområde og skal kunne forsvare deres bedømmelser opad i systemet.

Benny Simonsen

Jeg mener at der for nogle år siden var et Open source projekt, som vragede Git fordi det ikke var muligt at fjerne noget fra versionshistorikken - f. eks. hvis der blev brugt noget som ikke måtte være med pga. licens, og skulle slettes - inkl. slettes i fortiden.

Jeg mener at det var FreeBSD, men husker jeg ret?

Under alle omstændigheder skal man da gøre sig umage for at lave om på historikken og ende op med samme checksum (SHA1's svaghed hjælper selvfølgelig).
Alt andet lige vil jeg mene at det er noget lettere at erstatte indholdet af en fil v. 1.2.3.4 med noget andet hvis der ikke er checksum.

> Og det forhindrer ikke på nogen måde at man bruge Git til det
> det er designet til og som det er rigtig godt til, nemlig gruppearbejde.

Er det Git's standardinstillinger der er problemet, således at f. eks. Gitolite eller Github med passende hooks er et versionsstyringsværktøj? - versionsnummeret må kunne sættes på som en del af push i f. eks. Gitolite.

Esben Nielsen

Vi har desværre haft et par situationer i FreeBSD hvor kode måtte fjernes fordi der ikke var helt styr på rettighederne.

Med SVN kan man gå ind og fjerne filerne i databasen. Dvs. nu er de problematiske filer væk i alle revisioner og man bryder ikke rettighederne ved at man kan tilgå alle historiske revisioner. Men når man kan det, kan man jo netop ikke samtigdig sige at revision 49152 en entydig størrelse.

Man kan simpelthen ikke få begge dele på een gang.

Hvis man med Git fjerner en fil i alle revisioner (det kan man godt lokalt og man kan endda push force det til en server), får man nye hashes. Men så kan alle jo netop se, at indholdet har ændret sig.
Og i praksis får man en hel masse problemer med udviklernes træer som refererer til de gamle hashes, så de skal selv lave samme øvelse før de kan pulle meningsfyldt fra serveren igen.

Jesper Louis Andersen

Jeg kan stadig huske quilt.sh. Dejligt lille værktøj til at holde en patch-stak til dit SVN repo fordi SVN dengang var for elendig til at strukturere branches. Mercurial lavede "queues" til samme formål, og git formaliserede det i høj grad i en interactive rebase-konstruktion.

Jeg kan godt se de her ting fra begge sider. Hvad PHK kalder "groupware" er virkeligt rart fordi det giver dig en masse gode værktøjer til at kunne behandle patches på en mere struktureret måde. Men det giver et noget mere broget billede når vi snakker om en lineær versionering. Hvis du skal have noget sporbarhed er du nødt til at have en monoton nummerserie.

Jeg er personligt med Alexander her. Hvis du har behov for en lineær historik, så er valget af Git, SVN, Hg, CVS, P4 osv en detalje. Det vigtige er at der findes et system der gatekeeper entry således at historik tvinges til at være lineær. Gerne med tvungen kodereview. Bemærk at den metode anvendes med success af Google (der stort set kører alt kode i et repo med en enkelt trunk. I.e., de har eksplicitte nummererede revisioner). I princippet står det dig frit at tagge hver git-commit med 1,2,3,... osv og så ville git fungere på samme niveau som SVN.

Hvis jeg skulle argumentere for en svaghed i Git kunne det være at hvert commit er et snapshot af et filsystem og der ikke spores hvordan filer flyttes rundt osv. Git benytter heuristikker til at regne ud hvordan en fil er blevet flyttet i snapshottet. I forbindelse med en sporbarhed kunne det argumenteres at dette ikke er tilstrækkeligt.

Til gengæld er mit bud også at det her en kamp PHK taber på lang sigt. Det bliver et Git-lignende system der ender med at få SVN-features såsom forløbende historik. Det bliver ikke et SVN system der adopterer strukturen i Git-modellen. Men langt mere sandsynligt er som sagt at begge modeller helt forkastes for et officielt code-review tool, en bot, som med hård hånd er bestyrer af repoet. Det er simpelthen for vigtigt til at sætte mennesker til. Specielt Linus :)

Esben Nielsen

Jeg kan ikke se, at man overhovedet kan snakke om en linear historik i et projekt med mange udviklere, og slet ikke, når der er branches involveret.
"svn update" ser linear ud ved simpelthen at skubbe lokale ændringer ind efter commits i repository. Samme gør "git rebase".

Men i virkeligheden er lokale commits og commits i repository sket parellelt og det er "fup" at linearisere dem. Med branches bliver det helt åbentlyst og svn linearisere heller ikke - den skjuler bare individueller ændringer sket på den anden branch i ét merge commit, så man har svært ved at spore, hvor ændringerne rent faktisk skete.

Esben Nielsen
Steen Thomassen

At der i Git er så mange forskellige måder at gøre det på og at der samtidig findes en nærmest uendelig strøm af hjælpe værktøjer til Git (fx Git Easy), er for mig tegn på et dårligt design.


Jeg tager det omvendt, at der mange værktøjer. Git er et stærk værktøj, hvor mange har interesse i det er nemt at arbejde med i det daglige.

I Git skal alle mere eller mindre være Git admin. Der er ikke meget KISS over Git.


I git kan alle brugere bruge det som alm. bruger. Man arbejder med sin egen kopi, som man kan pull/push ændringer til/fra i forhold til andre kopier (og evt. en master)

Esben Skov Pedersen

Thomas, jeg har læst dit link og der står ikke at der kan være mere end to. Der står parents i flertal. Normalt har et commit 1 parent. Merge commits har 2. Det første commit i et repo har 0.

Jeg vil selvfølgelig gerne høre hvis du kan tweake systemet til noget andet, men ved normal brug er der op til 2.

Martin Olsen

Er gammel nok til at have arbejdet med både CVS, SVN og git i forskellige virksomheder. Uanset system, så har revisionnummer/SHA altid været til intern brug. Til ekstern brug har man tagget med et versionsnummer, når man releaser. Har endnu til gode at møde en kunde, der interesserede sig for, om vores VCS internt brugte fortløbende number eller SHA.

Claus Gårde Henriksen

Interessant FUD tråd om Git. Kan det virkelig passe det ikke er versionskontrol? Kan man bruge FDA kortet mod Git? Forsvinder ting (ikke?) fra mainline?
Uha, det er hårde påstande som kan starte en brand i virksomheden.

Jeg mangler stadig at finde det idiotsikre versionskontrol værktøj, hvor man ikke kan smadre master/main-stable. Jeg mangler også at se det versionskontrolværktøj, der ikke bliver skældt hæder og ære ud af folk der har valgt noget andet.

Rasmus Villemoes

Prøv det her:

git init   
echo x > x && git add x && git commit -m x  
git checkout -b a master  
echo a > a && git add a && git commit -m a  
git checkout -b b master  
echo b > b && git add b && git commit -m b  
git checkout -b c master  
echo c > c && git add c && git commit -m c  
git checkout master   
git merge --no-ff a b c -m 'octopus!'  
git show

giver noget i retning af

commit f885ec53cfd5d11e1a6c020e3ab5badf2c43b86f  
Merge: 407b21c bec98c2 c614c78 ebd8868

Så jo, man kan sagtens merge flere branches på en gang, og resultatet er et merge commit med n+1 parents.

Brian Vraamark

Men i virkeligheden er lokale commits og commits i repository sket parellelt og det er "fup" at linearisere dem. Med branches bliver det helt åbentlyst og svn linearisere heller ikke - den skjuler bare individueller ændringer sket på den anden branch i ét merge commit, så man har svært ved at spore, hvor ændringerne rent faktisk skete.

Jeg synes netop at Git er fup. En merge fra en branch til en anden i git blander historik sammen.

For mig er branches ligesom to forskellige personer, med hver deres erindringer. Når en person fortæller mig om noget han har oplevet, så står det i min "historik" på den dag han fortalte det. Hans historie er måske sket hen over længere periode, men for mig er dette fortalt og registeret på en dag. Han laver en merge i min hukommelse.

I øvrigt synes jeg at sporbarheden er meget simpel. Hvis jeg ønsker at se historik for en ændring på en bestemt fil i min trunk, så kalder jeg log på den. Når jeg har fundet den merge der er skyld i ændringen, kan jeg jo se hvilken branch den kommer fra. En efterfølgende log på denne branch, giver mig den fulde detaljerede historik inklusiv hvornår det skete i virkeligehed.

For mig er SVN som to personer der fortæller hinanden en historie, mens Git er en sammensmeltning af disse to personers hukommelse (aka Git lider af personlighedsspaltning).

Personligt er jeg ikke interesseret i, at man i trunk/master kan se at koden er rettet flere gang (måske pga ping-pong mellem udvikler og tester). Jeg ønsker kun at se det endelige resultat i trunk/master. Jeg kan derfor altid lave en revert til et hvilket som helst versionsnummer og få en version af produktet som (burde) virke og er testet. I Git skal jeg selv holde styr på det (fx via tagging).

Det skal siges at jeg kun har brugt Git i en kort periode og jeg synes der er rigtig mange fede ting ved Git, men jeg kan bare ikke undvære den lineære historik man kan få i SVN.

Anders Reinhardt Hansen

For mig er branches ligesom to forskellige personer, med hver deres erindringer. Når en person fortæller mig om noget han har oplevet, så står det i min "historik" på den dag han fortalte det. Hans historie er måske sket hen over længere periode, men for mig er dette fortalt og registeret på en dag. Han laver en merge i min hukommelse.

Ikke hvis du bruger rebase inden merge, så bliver historien fuldt ud lineær fordi rebase placerer alle commits lige inden merge.

I øvrigt synes jeg at sporbarheden er meget simpel. Hvis jeg ønsker at se historik for en ændring på en bestemt fil i min trunk, så kalder jeg log på den. Når jeg har fundet den merge der er skyld i ændringen, kan jeg jo se hvilken branch den kommer fra. En efterfølgende log på denne branch, giver mig den fulde detaljerede historik inklusiv hvornår det skete i virkeligehed.

Det kan man også i git, det hedder merge squash commit, det kan man bruge som alternativ til rebase hvis det er for komplekst.

Anders Reinhardt Hansen
Kristian Rastrup

Hvis man laver en central udvikling af et større projekt er der behov for 1 sandhed, nemlig den dine build- og deployservere lytter til. Det understøttes fint af et centralt VCS som SVN eller TFS.
Her høster man ikke mange fordele ved at kunne clone til højre og venstre.
Hvis man derimod laver et løst organiseret OSS projekt er det netop i ånden at hvis nogen vil noget andet end de andre kan de bare lave en clon og skabe deres egen udvikling derfra.

Det virker som en meget følelsesladet ting hele denne tråd.
Måske sidder jeg som MS udvikler med Stockholm syndrom men de fleste MS udviklere kører TFS (nogen har skiftet til Git, bevares men stadig på TFS og med den som central server). Det er sjældent til diskussion for sådan gør "man" og det passer som fod i hose til Visual Studio.
Til gengæld hygger jeg mig med mine popcorn her fra sidelinjen :)

Brian Vraamark

Du kan tvinge Git til ikke at acceptere merge-commits og dermed tvinge "lineær historik" igennem (dog ikke ift. tid, hvilket også er ligemeget), så er problemet med den ene idiot løst, personen får en fejl og bliver nød til at lave et rebase af sine ændringer før de kan komme videre.

På Github er det her et flueben væk og derefter behøver du ikke tænke mere over det problem.

  • Du kan tvinge..
  • Lave et rebase...
  • GitHub

Igen en masse regler som skal følges. Og hvorfor skal jeg bruge GitHub for at Git bliver nemt at bruge?

I øvrigt at rebase altid beskrevet med en "Use caution". Lige netop fordi en rebase giver problemer med sync mellem din lokale branch og den som befinder sig remote (jeg har en remote fordi jeg vil dele den med en anden). Nåår ja, så kan man bruge force push og fuldstændig ændre historik remote (der forsvandt sporbarheden). Så må man bare håbe at der ikke er andre som har lavet en checkout på denne branch.

Sune Marcher

Igen en masse regler som skal følges.


Regler der kan implementeres som policies så det ikke er noget du har mulighed for at glemme.

Igen en masse regler som skal følges. Og hvorfor skal jeg bruge GitHub for at Git bliver nemt at bruge?


"Hvorfor skal jeg bruge et centralt repository for at have et workflow der forudsætter et centralt repository?" - der er ingen der tvinger dig til at bruge GitHub, der er andre muligheder.

Git integrerer derudover ganske nydeligt i Visual Studio. Jeg kunne ikke drømme om at vælge TFS.

Martin Bøgelund

Hvorfor er det tankevækkende at SVN er elendigt til noget det er designet til ikke at gøre ?

Det tankevækkende er, at man som udviklingsgruppe foretrækker et værktøj, der ikke har nogen talenter indenfor den diciplin der går ud på at få gruppemedlemmernes arbejde til at fungere sammen.

EDIT: Lad mig gætte... FreeBSD-udviklere betragter sig ikke som gruppe, men som et bundt individualistiske rethavere, der hver især er klogere end resten af verden, og derfor foretrækker et rigidt værktøj til at afgøre interne stridigheder om hvordan ting skal gøres, fremfor at skulle vise people skills og evnen til at se ting fra et andet perspektiv?

Ole Laursen

Hvorfor er det tankevækkende at SVN er elendigt til noget det er designet til ikke at gøre ?

Lad os lige få lidt fakta på bordet. CVS var et system til at samarbejde om versionstyring, det ligger i navnet:

https://en.wikipedia.org/wiki/Concurrent_Versions_System

Som jeg husker det, var det en slags frontend til RCS.

Subversion er en reimplementering af CVS.

Begge værktøjer havde som erklæret mål at gøre det muligt at samarbejde om at udvikle kode.

Så kan man kalde det hvad man vil.

I øvrigt ellers enig i at SVNs model med én master (som i git kan laves med rebasing) i mange tilfælde giver mere mening end en arbitrær versionsgraf, og jeg finder det stadig lidt deprimerende at almindelige dagligdags ting som bare virker i SVN i denne vigtige model, stadig er lidt halvdårligt understøttet i git. F.eks. hvis man sidder og arbejder på en fil og så gerne vil have suget en fejlrettelse ned fra master/trunk/en kollega, men ikke har brug for at lave et commit hverken før eller efter.

Malik Taaning

Det er sjældent man ser en mere effektiv diskussion end den du (PHK) har med dig selv i denne tråd.

Først lister du 3 kvaliteter som alle 'sande' VCS skal have.
Dernæst påstår du at alle de kvaliteter er opfyldt af SVN og ikke af Git

I dine kommentater kommer du dog med klokkeklare indrømmelser om at SVN IKKE opfylder de 3 krav (e.g behovet for at 'få noget til aldrig at være sket'.)

Det er rigtigt at man for at opnå dine 3 krav skal konfigure Git, men det er muligt.
Og der er mange gode posts i tråden der beskriver hvordan.
Med SVN står du tilbage med håb og en blind tillid til din sysadmin som kan slette, rette og regere som han lyster.

Du lader til at have en stålsat holdning på det her område som ikke lader sig påvirke af fakta - det er synd.

Sune Marcher

VS 2013 og frem ja. Som jeg skrev kører nogen også med git ud fra en TFS server. Stadig med samme centralistiske tankegang. Umiddelbare fordel frem for andre Git servere: Backend er Sql Server i stedet for et fildrev.


Var 2013 ikke blot tidspunktet hvor Microsoft tilføjede officiel Git-support? Jeg synes at kunne huske at have anvendt det i VS tidligere end dét - under alle omstændigheder startede jeg i hvert fald med et 3rd-party addon.

At backend er SQL server ser jeg ikke nogen umiddelbar fordel i, blot ekstra overhead. Du tilgår jo ikke dit repository som CIFS/NFS-adgang til .git folderen, men via Git protokollen til en daemon, der derefter har den lokale filadgang. Altså, du kan naturligvis tilgå et remote repo ret direkte, og det kan være en fin ting at have mulighed for - men det er ikke det typiske setup.

Du kan for øvrigt læse more om Gits prokoller her.

Finn Aarup Nielsen

Hvis jeg må have lov til at afspore debatten.

I Python-udviklingen løber jeg ind i det spørgsmål hvad man skal gøre for at sammenkoble git versioneringen med den versionering man ser/sætter i Python's setup og problemet med hvad man skal kalde versioner mellem release 1.2 og 1.3.

På et repo har jeg nu begyndt med versioneer der er beskrevet her https://blog.mozilla.org/warner/2012/01/31/version-string-management-in-...

Versioneer sætter versionen automatisk og her kan en version hedde "1.4-8-gf7283c2-dirty" hvor første del (1.4) er det menneskesatte tag, næste del en tæller, derefter sha1 og tilsidst indikering om der mangler commit.

Mit første forsøg i dag er indtil videre gået nogenlunde. Jeg gad vide om der er andre der har erfaringer med versioneer?

Poul-Henning Kamp Blogger

Det tankevækkende er, at man som udviklingsgruppe foretrækker et værktøj, der ikke har nogen talenter indenfor den diciplin der går ud på at få gruppemedlemmernes arbejde til at fungere sammen.

FreeBSD er et utroligt fladt projekt hvor noget der nærmer sig trehundrede mennesker har direkte adgang til at commit'e rettelser direkte til det centrale VCS.

I Linux skal du igennem en masse lag før dine rettelser bliver committet af Linus selv.

Det burde give sig selv hvorfor der stilles forskellige krav til det værktøj der holder styr på det centrale træ.

Kristian Rastrup
Poul-Henning Kamp Blogger

Jeg må indrømme at jeg er lidt imporeret over hvor meget ureflekteret fanboiretorik det vælter ud med her.

Ikke mindst undrer det mig at disse fanboi's er i stand til totalt at ignorere hvad der står i en af de allerførste sætninger i blogindlægget:

"Det forbavser mig til stadighed at de fleste mennesker omtaler Git som "versionskontrol", for det er det vitterligt ikke - det er noget meget smartere og mere moderne." (min fremhævelse).

Ligeledes undrer det mig også, at ingen af disse fanboi's har brugt bare tre minutter på at overveje om der faktisk er behov for frådende at forsvare Git imod mig, når jeg selv har en stak projekter på github, inklusive mit opus magnum, Varnish ?

Fatter pap & 250g/m² karton:

Nej, uanset hvad i siger og påstår er git ikke et VCS.

Det er en God Ting for mindst 99.99% af alle respositories.

Men for de sidste 0.01% er et rigtigt VCS et bedre værktøj.

Sune Marcher

Det mest almindelige 3rd-party var forfærdeligt og kun til VS 2012. Udvikling på det stoppede med at VS 2013 blev introduceret.


Hm, det jeg brugte fungerede upåklageligt - så vidt jeg husker var der to, hvor det andet fungerede noget ringere.

Det giver fordele for transaktioner, backup, kryptering, load balancing, failover mm. som et fildrev kun kan drømme om.


Én gang til for arveprins Knud: du tilgår ikke et central repository som "fildrev". Du kommunikerer via Git-protokollen, og servicen bag kan sådan set gøre hvad den vil - Github og Bitbucket ser ud til at klare load balancing og alt det jazz fint uden at prøve at mose et repository ned i en SQL backend.

Jeg har ikke læst Git sourcen, men hvis der var transaktionsproblemer havde vi nok hørt om det... og backup og kryptering kan altså også sagtens håndteres uden at du skal have en SQL-server indover.

Bevares, hvis du allerede har en MSSQL kørende i din organisation kan det da give mening at benytte eksisterende know-how i stedet for at sætte et helt nyt system op - men det er ikke det samme som at du ikke kan få feature parity uden.

Kristian Rastrup

Én gang til for arveprins Knud: du tilgår ikke et central repository som "fildrev". Du kommunikerer via Git-protokollen, og servicen bag kan sådan set gøre hvad den vil - Github og Bitbucket ser ud til at klare load balancing og alt det jazz fint uden at prøve at mose et repository ned i en SQL backend.

Jeg tror vi snakker ud fra forskellig kontekst. Min er hvad store konservative virksomheder vil gå med til og der er selv MS egen visual studio online vovet så da slet ikke Github eller bitbucket.
Og hvordan man end snakker med VCS skal der stadig laves backup hvis man har serveren kørende lokalt.

Bevares, hvis du allerede har en MSSQL kørende i din organisation kan det da give mening at benytte eksisterende know-how i stedet for at sætte et helt nyt system op - men det er ikke det samme som at du ikke kan få feature parity uden.

Slet ikke, men hvorfor selv opfinde den dybe tallerken når andre har gjort det for dig?

Sune Marcher

Jeg tror vi snakker ud fra forskellig kontekst. Min er hvad store konservative virksomheder vil gå med til og der er selv MS egen visual studio online vovet så da slet ikke Github eller bitbucket.


Det har du skam helt ret i. Jeg kender dog en stor og rimeligt konservativ dansk virksomhed der kører on-premise Bitbucket - og en del af deres C# er vist på vej i MS's sky.

Og hvordan man end snakker med VCS skal der stadig laves backup hvis man har serveren kørende lokalt. [...] Slet ikke, men hvorfor selv opfinde den dybe tallerken når andre har gjort det for dig?


Det er jeg sådan set også enig i - til gengæld vil jeg gå ud fra at man, hvis man self-hoster, allerede har styr på normal backup-procedure. Ellers er sammenligningsgrundlaget vel at man ikke pt. har en SQL server kørende, og skal til at sætte en op samt få styr på credentials, backup-procedurer og så videre.

Og hvis man er villig til at bruge hosted TFS, så er sammenligningsgrundlaget en af de professionelle Git services, ikke "Git repository hosted over NFS/CIFS på en gammel afdanket filserver uden backup" ;-)

Esben Nielsen

Det er nok fordi du selv starter med at kalde Linus Torvalds en klaptorsk og taler meget grimt og nedladende om Linuxkerne-udviklerne. Så er nivauet ligesom lagt.

Vi andre prøver med saglige argumenter at modsvare din grundlæggende påstand om at Git ikke et "rigtigt versionkontrol" på højde med SVN - og får ikke rigtigt noget logisk svar, der med rimelighed kan argumentere for din påstand.

Men vi basher dig og er bare ureflektere fanbois.

Du må da vist lært af en vis herre der lige er flyttet til Washington DC...

Alexander Færøy

Jeg må indrømme at jeg er lidt imporeret over hvor meget ureflekteret fanboiretorik det vælter ud med her.

Det må du havde vidst ville ske i det øjeblik du, i selvsamme indlæg, havde behov for at kalde Linus en klaptorsk for et design af et værktøj, der har vist sig at være en uhyre populær måde at lave SCM på, og derefter, sikkert ganske reflekteret, at kalde Git for "groupware". Et ord, der sikkert uden nogen videre grund, giver en dårlig smag i munden for mange folk i IT branchen og for de flestes vedkommende strækker sig over langt mere end blot "source code management" for tilsidst at afslutte indlægget med en svag analyse omkring hvad 0.01% af software projekter har behov for, når der er dele af den process, der er uendeligt meget mere spændende end selve valget af VCS/SCM.

Du kunne havde toppet indlægget med en afsluttende kommentar om at systemd er vejen frem og Lennart burde blive hædret ved næste mulige lejlighed for hans arbejde med at få Unix ind i dette årtusinde. :-)

Poul-Henning Kamp Blogger

Det må du havde vidst ville ske i det øjeblik du, i selvsamme indlæg, havde behov for at kalde Linus en klaptorsk for et design af et værktøj [...]

Det var det med at læse indenad igen, var det ikke?

Jeg kalder ham ikke klaptorsk for at have designet Git, men for ikke at forstå hvad versionskontrol er.

Det er jeg forresten på ingen måde ene om, RedHat, IBM og mange andre store corporate Linux-players råbte og skreg om det i næsten 15 år før han overhovedet forstod hvad versionskontrol gik ud på og hvorfor folk måtte ønske sig det...

Michael Cederberg

Jeg tror vi snakker ud fra forskellig kontekst. Min er hvad store konservative virksomheder vil gå med til og der er selv MS egen visual studio online vovet så da slet ikke Github eller bitbucket.
Og hvordan man end snakker med VCS skal der stadig laves backup hvis man har serveren kørende lokalt.

Jeg kender adskillige store virksomheder som er ganske lykkelige for bitbucket, svn og/eller tfs. Jeg synes at nogen af dem er konservative, men ingen af dem har udtrykt mistillid til nogen af løsningerne. Der er forskel i features og så er der historik, og det er typisk grunden til at man vælger at køre en eller flere af dem.

Hostede løsninger kan jeg ikke forestille mig nogen store virksomheder vil vælge med mindre data krypteres lokalt.

Personligt er jeg en sen konvertit når det gælder git (kloge yngre kollegaer lavede et kup). Jeg havde svært ved at se fornuften i et distribueret source code repo når nu alt alligevel skulle ned på en central server. Jeg overså hvor godt hele branch/merge strategien fungerer i git og hvordan det bliver en naturlig del af dagligdagen. I dag kan jeg ikke se nogen grund til at vælge andet, selvom både tfs og svn begge er strålende produkter.

Alexander Færøy

Jeg kalder ham ikke klaptorsk for at have designet Git, men for ikke at forstå hvad versionskontrol er.

Det er jeg forresten på ingen måde ene om, RedHat, IBM og mange andre store corporate Linux-players råbte og skreg om det i næsten 15 år før han overhovedet forstod hvad versionskontrol gik ud på og hvorfor folk måtte ønske sig det...

Linux er et lousy eksempel på misforstået eller manglende brug af "et rigtigt VCS". Det viste sig heldigvis at være fløjtende ligegyldigt om Linus tog fejl eller ej eftersom alle overnævnte virksomheder i dag aktivt bidrager til Linux med en SCM model som åbenbart både deres advokater samt udviklere må kunne leve med - helt uden at kunne se om kernel/sched.c er version 1.3.3.7 og andet fnidder som der kun er behov for i de førnævnte 1% af vores software projekter.

Pointen med at der ikke var nogen grund til at kalde Linus for en klaptorsk, i et indlæg hvor hans person og diverse misforståelser han har måtte haft igennem udviklingen af Linux, er rasende ligegyldige står stadig.

Jesper Louis Andersen

I en linear historik gælder det ikke at tidspunktet hvor noget er skrevet på ligger fast historisk. Hvis det skulle være tilfældet skulle man have et system som RCS hvor en fil låses før man retter i den og låses op bagefter. I praksis har man en linearization, i den forstand at der findes et bestemt (atomisk) punkt i tiden hvor en patch kom med end i kildekoden. Tidspunktet mens at udviklingen stod på varierer ofte. Det er ikke ualmindeligt at en patch har levet hos en udvikler længe inden den kommer med. Så linearization er i høj grad hvad der sker.

Men i den distribuerede verden er det ofte en form for causality der er nødvendig og dette begreb er væsentligt svagere end linearization. Spørgsmålet er om man i praksis ville kunne leve med denne grad af præcision, også selv om virksomheden er kæmpestor. Ideen er at det er nok at vide "Det her sæt at patches kom før det andet" men ikke nødvendigvis behøver at kende ordningsdetaljer indenfor patchsættet. F.eks. lader mange patches sig omordne uden at det kan ses: f.eks. to patches der piller i to forskellige filer uden at have nogen indvirkning på hinanden.

Jeg har lidt på fornemmelsen at Git er tættere på en causal model end en linearization model. Simpelthen fordi dette er den eneste ting der ville virke i et distribueret system. Men spørgsmålet er lidt om det virkeligt er bedre at have en linearization når den nu engang ofte er ligegyldig.

Poul-Henning Kamp Blogger

Pointen med at der ikke var nogen grund til at kalde Linus for en klaptorsk, i et indlæg hvor hans person og diverse misforståelser han har måtte haft igennem udviklingen af Linux, er rasende ligegyldige står stadig.

Siden hvornår er Linus blevet en ufejlbarlig helgen der ikke må kritiseres ?

Og tag dig lige tid til at se den video jeg linkede til, inden du giver dig til at være dommer over sprogbrug og god takt og tone omkring Linus...

Morten Siebuhr

SVJV startede git som et "directory content tracker system" og Linus' håbede/tænkte/regnede med at nogen ville pakke "rå" udgave ind i noget pænt SVN/HG/BZR-CLI ... hvilket bare aldrig skete.

Der er endda et commit hvor dokumentationen går fra at beskrive et versioneret filsystem (med lidt sukker ved siden af) til et SCM hvor du kan lege med indvoldene.

Jeg mindes at ha' set i al fald to-tre forsøg på at udstille et pænere interface til Git (som regel ved at påtvinge bestemte workflows). I test klarer de sig ret godt, men "rå" git har vist for meget momentum til at de kommer nogle steder...

Alexander Færøy

Siden hvornår er Linus blevet en ufejlbarlig helgen der ikke må kritiseres ?

Du må kritisere hvem som helst ligeså meget du vil, men du må også forvente at folk reagerer derefter og det dermed påvirker den debat du ønsker.

Og tag dig lige tid til at se den video jeg linkede til, inden du giver dig til at være dommer over sprogbrug og god takt og tone omkring Linus...

Linus er præcis ligesom alle de andre ærkekonservative, ældre, hackere i vores lille open source andedam: bedrevidende, snæversynet, kritiserer alt og alle der ikke deler hans holdning om ting, et kæmpe røvhul, osv. osv. osv. Hans personlighed bør på ingen måde være et forbillede for yngre hackere.

Har intet behov for at gense den video.

Morten Mathiasen

Opsummering af saglige argumenter mod GIT med tilhørende foreslåede løsninger:

  1. Historiske commits kan slettes.
    Der er 2 simple kommandoer til at sikre historik af alle commits:
    [cmds]
    git config --system receive.denyNonFastForwards true
    git config --system receive.denyDeletes true
    [/cmds]
    Er det for strenge restriktioner kan rettigheder tildeles udvalgte brugere/branches, f.eks. vha. hook

  2. Læsevenlige versionsnumre mangler.
    Man kan tilføje tags, der navngiver commits med versionsnumre.

Herefter tilbagestår blot et valg af hvilket VCS, som man bedst kan lide at bruge, og her tyder det på at mange i tråden ville vælge GIT
Måske er der basis for et lille projekt, der fintuner GIT man passende standardindstillinger for etablering af versionsnumre og historisk sikkerhed

Malik Taaning

Det er en God Ting for mindst 99.99% af alle respositories.

men man er en klaptorsk hvis man vælger det til software projekter med en pris på over 1mill?

Igen, dine argumenter i den her tråd er usammenhængende og modstridende.
Der udover ville det klæde dig ikke at ty til latterliggørelse og ad hominem angreb når ikke dine argumenter rækker.

Dine 3 kriterier for hvad et VCS skal kunne er stadig bedre dækket af Git end af SVN - og det var der debatten startede.

Martin Bøgelund

FreeBSD er et utroligt fladt projekt hvor noget der nærmer sig trehundrede mennesker har direkte adgang til at commit'e rettelser direkte til det centrale VCS.

I Linux skal du igennem en masse lag før dine rettelser bliver committet af Linus selv.

Det burde give sig selv hvorfor der stilles forskellige krav til det værktøj der holder styr på det centrale træ.

Her er der intet vi kan blive uenige om.

Men når jeg Googler definitionerne på "Groupware" og "VCS" synes jeg det er en lige lovlig skarp udmelding, at påstå Git ikke er et VCS, og at påstå at SVN ikke er groupware.

Det virker jo meget tilforladeligt når du åbner ballet med at FreeBSD-projektet diskuterer et skifte fra SVN til Git.

Som andre end jeg lader til at have bemærket, skinner der dog nogle aversioner mod Linus/Linux/Git igennem i dit blogindlæg, som måske har udspring i et bagkatalog, som - meget behændigt - ikke lige er nævnt i blogindlægget, og hvor Git's feature set misbruges til at klaske ovenstående i hovedet.

Ordet "klaptorsk" opfattes f.eks. aldrig som kompliment, uanset kontekst.

Og så er det du får noget røg fra "pingvinisterne".

F.eks.:

Men hvis man har brug for rigtig versionkontrol er det smartere at automatisere opgaven med et rigtigt [min fremhævelse] versionskontrolsystem.

Differentieringen mellem "versionskontrol", og "rigtig versionskontrol", skriger jo på at vi er ude i noget "no true scotsman"-argumentation. Jeg vil mene at hvis du nu føler noget pushback fra pingvinisterne er det selvforskyldt.

Claus Gårde Henriksen

Nåh ja. "Hver ting til sin tid". Citat: Alfons Åbergs far. Man kan godt bruge cvs/rcs/svn/... uden at skulle skamme sig. Det værste at undlade brug af versions kontrol... eller git, he he. Undskyld. Jeg er også ny git bruger.

Benny Simonsen

Jeg mener at det var FreeBSD, men husker jeg ret?

Ja, som sagt ovenfor var det et ufravigeligt krav til vores VCS.

Jeg mener at det var FreeBSD, men husker jeg ret?

Ja, som sagt ovenfor var det et ufravigeligt krav til vores VCS.

Jeg er vist forvirret ... jeg vil da mene at argumenterne mod Git har gået på manglende versionsnumre/juristeri, men hvis det er lettere at ændre i historikken i SVN end i Git må det da være et kvalitetsstempel på Git, selvfølgelig trelst hvis man har brug for at fjerne noget fra historikken.

Altså er der ingen diskusion om hvad git commit "ab12..." indeholder, uanset rettigheder (dog med forbehold for SHA1's svaghed), for SVN ville version 1.2.3 godt kunne være ændret (med nødvendige rettigheder).

PS: Det kan sagtens lade sig gøre at fjerne noget fra Gits historik, men det bliver med nye SHA1 sums (vil ske i en ny branch der deler sig før det der skal fjernes kom med).

Tobias Tobiasen

[qoute]Jeg er ikke ekspert i Git repo konfiguration men jeg går ud fra at de settings du beskriver kan slås fra og til efter behov hvilket fjerner deres værdi i en sporbarhedskontekst.
[qoute]
God pointe!


Hvad er pointen lige her?
At hvis man har administrator rettigheder til den centrale git repository så kan man slå force commit protection fra og det så giver sporbarhedsproblemer?

Jeg lover dig hvis jeg får administrator rettigheder til din SVN server så kan jeg også skabe sporbarhedsproblemer.

Så må pointen være at hvis du gerne vil have sporbarhed så skal du beskytte din master repository uanset hvilket version styrings system du vælger.
Git har dog en lille fordel at du rent faktisk kan se hvis nogen har pillet ved historikken. I subversion vil det være sværere at opdage hvis en admin har ændret historikken noget på serveren.

Log ind eller opret en konto for at skrive kommentarer