w18-20: Git

[Per Andersson]

Skapar ny tråd för nästa ämne.

2010/4/27 igno <er...@jutemar.se>:
> Förslag:
> Ingående diskussion av Git. Hur/var/när/varför och hur man löser
> vanliga problem som till exempel konflikter, patchar, branches osv.
>
> - Erik

Några lästips där vi kan börja, ordnade från översikt till teori till
praktik nedan.

http://en.wikipedia.org/wiki/Git_(software)

http://eagain.net/articles/git-for-computer-scientists/

http://www.kernel.org/pub/software/scm/git/docs/everyday.html

http://git.or.cz/course/svn.html


-- Per


--
Subscription settings: http://groups.google.com/group/anarthesis/subscribe?hl=en

[Per Andersson]

2010/4/27 Per Andersson <avto...@gmail.com>:

> Skapar ny tråd för nästa ämne.
>
> 2010/4/27 igno <er...@jutemar.se>:
>> Förslag:
>> Ingående diskussion av Git. Hur/var/när/varför och hur man löser
>> vanliga problem som till exempel konflikter, patchar, branches osv.
>>
>> - Erik
>
> Några lästips där vi kan börja, ordnade från översikt till teori till
> praktik nedan.
>
> http://en.wikipedia.org/wiki/Git_(software)
>
> http://eagain.net/articles/git-for-computer-scientists/
>
> http://www.kernel.org/pub/software/scm/git/docs/everyday.html
>
> http://git.or.cz/course/svn.html

Sen finns det lite onlineböcker och resurser också

http://progit.org/

http://git-scm.com/documentation


Jag har en hel del repositories i git om någon vill kolla hur jag
brukar göra, hojta i sådana fall.

[Per Andersson]

2010/4/27 Peter Miscevic <peter.m...@gmail.com>:
> Mercurial är ganska fint också. =) Färre funktioner men väldigt lättanvänt.

http://wiki.sympy.org/wiki/Git_hg_rosetta_stone

"The first and the most important thing is that you should understand that git
is different. For example it uses staging area (so called index) for iteratively
preparing commits. This and other great and unique features of git make it
really superior to hg and other SCMs I've ever seen, so go read its
documentation - you would not regret!"

[Hedvig Kamp]

För den som inte orkar läsa och/eller gillar att lyssna på Linus Torvalds. :)

http://www.youtube.com/watch?v=4XpnKHJAok8


-- Hedda

[Per Andersson]

Försök posta i rätt tråd!

2010/4/27 Tomas Vestelind <tomas.v...@gmail.com>:
> och är GIT bättre än SVN? Varför?

Läs till exempel http://hginit.com/00.html

"It turns out that if you’ve been using Subversion, your brain is a little bit,
um, how can I say this politely? You’re brain damaged."


Några skäl:

SVN är centraliserat, har inte bra stöd för brancher och tags, har inte bra stöd
för mergning (för att brancherna har för lite information för att merga
ordentligt), svn spårar (eng. tracks) filer.

Git är snabbt (dels på grund av att allt görs lokalt, dels på grund av att det
är byggt med prestanda i åtanke från första början), det är decentraliserat (du
kan committa utan att ha tillgång till ett centralt repository), brancher och
tags fungerar bra, mergningar fungerar utomordentligt bra.


-- Per

[Sebastian Jansson]

2010/4/28 Per Andersson <avto...@gmail.com>

[...] det är decentraliserat (du kan committa utan att ha tillgång till ett centralt repository), [...]

Tomas: en annan fördel med att GIT är just decentraliserat är att man kan jobba på ett helt annat sätt. Om du och jag tillsammans med 20 kollegor sitter och kodar på nåt stort och jag har gjort en fräck grej som jag vill visa dig men ingen annan (kanske en jättestaty av lenin infogad i vårt superseriösa MMORPG), så kan jag med lämpliga rättigheter commita mina ändringar till ditt lokala repository utan att behöva gå omvägen via ett centralt dito. 

Det gör att man enklare kan experimentera med kod, och tillsammans med mycket bättre branch-möjligheter blir det roligare att göra stora förändringar. Mindre krångel.

Som exempel på GITs snabbhet så kan jag byta mellan version 1.0 och 2.5 av mitt energistatistikprogram, dvs flera tusen ändrade filer och ganska mycket annan struktur, på en halv sekund eller så. Hade jag behövt göra det via nån slö central SVN-server hade det tagit tiiiid.

Vänliga hälsningar,
Sebastian

[Tomas Vestelind]

Ok, jag visste inte att det funderade så. Ska läsa lite om det. 

2010/4/28 Sebastian Jansson <se...@sebbz.se>

--
Quand on veut un mouton, c'est la preuve qu'on existe

[Jonas Ådahl]

Det finns faktiskt en sak som i dagsläget är svårt, om inte omöjligt,
att göra, nämligen ha sub-repositories som är "bleeding edge".

Det jag menar är följande scenario:
Vi har projektet "foo", som är ett bibliotek med viss funktionalitet.

Vi har sen projektet "bar" som är en applikation som använder
biblioteket "foo". "foo" och "bar" utvecklas väldigt tätt ihop, de är
i princip samma applikation, fast uppdelat i två logiska delar.

Den funktionalitet som finns i git för att lösa detta problem med
beroende mellan repositories är "submodules". En submodul fungerar så
att man har ett vanligt git repository. I detta git repository har man
vanliga filer och en lista på commits, historian. Samtidigt har man
lagt till en submodul, och git håller då reda på vilken commit, samt
vilken upstreamadress repot har. Ifall submodulen (vilket i princip är
en länk till ett annat repo samt en versionspekare) behöver
uppgraderas så måste man manuellt gå in, ladda ner och pull:a
ändringarna. För att sedan superrepositoriet (det där submodulen är
tillagd) skall peka på rätt commit måste man säga åt git att uppdatera
commitpekaren, vilket görs via "git add [path till submodulen]; git
commit". Problemet med detta är att man kan ej ha ett repo som speglar
nyaste versionen av ett annat repo.

En sådan här setup är möjligt i subversion.

Ett annat problem med submoduler i git är, ifall du använder ett så
kallat superrepository för att samla ihop ett antal repositorier, där
det repositorie du arbetar i ej är superrepositoriet, kan du, på grund
av samma problem nämnt ovan, få ditt superrepository att peka på
nyaste commit:en utan att manuellt uppdatera versionen. Detta gör att,
ifall du arbetar i en submodul i ett superrepository, så måste du
commit:a varje ändring två gånger; en gång i submodulen, samt en gång
i superrepositoriet.

Det problemet är också lösbart i subversion, men i dagsläget, så vitt
jag vet, ej i git.

Det finns lite "hack" här och var som löser det genom att hitta på
egna superrepositorielösningar och liknande. Är det någon som har
någon alternativ idé på hur det kan lösas?

On Apr 28, 1:29 pm, Tomas Vestelind <tomas.vestel...@gmail.com> wrote:
> Ok, jag visste inte att det funderade så. Ska läsa lite om det.
>
> 2010/4/28 Sebastian Jansson <se...@sebbz.se>
>
>
>
>
>

> > 2010/4/28 Per Andersson <avtob...@gmail.com>

[Jonas Ådahl]

> Ett annat problem med submoduler i git är, ifall du använder ett så
> kallat superrepository för att samla ihop ett antal repositorier, där
> det repositorie du arbetar i ej är superrepositoriet, kan du, på grund
> av samma problem nämnt ovan, få ditt superrepository att peka på
> nyaste commit:en utan att manuellt uppdatera versionen. Detta gör att,
> ifall du arbetar i en submodul i ett superrepository, så måste du
> commit:a varje ändring två gånger; en gång i submodulen, samt en gång
> i superrepositoriet.

Korrektion: .. kan du INTE, på grund av samma problem nämnt ovan, få
ditt superrepository att peka på nyaste commit:en i en submodul utan
att manuellt uppdatera versionspekaren i superrepositoriet.

[Per Andersson]

2010/4/30 Jonas Ådahl <jad...@gmail.com>:

Känns som att en någon slags hook kanske kan lösa detta?


-- Per

[Jonas Ådahl]

Menar du att ifall man commit:ar på submodulen så har man en hook som
commit:ar superrepot så det pekar på den nya commiten? Det skulle
alltså innebära att man skulle ha duppel uppsättning av varje commit,
alltså en dubbelt så lång commit log. Sen vet jag inte hur bra en hook
kan automatiskt lösa kollisioner, ifall det skulle uppstå.

Har du någon konkret ide på hur hooksen skulle fungera?

Jonas

[Per Andersson]

2010/5/3 Jonas Ådahl <jad...@gmail.com>:

> Menar du att ifall man commit:ar på submodulen så har man en hook som
> commit:ar superrepot så det pekar på den nya commiten? Det skulle
> alltså innebära att man skulle ha duppel uppsättning av varje commit,
> alltså en dubbelt så lång commit log. Sen vet jag inte hur bra en hook
> kan automatiskt lösa kollisioner, ifall det skulle uppstå.

Ja, dubbel commitlog skulle det innebära. Kollisioner är ju ett problem.

> Har du någon konkret ide på hur hooksen skulle fungera?

Nej, tyvärr.


-- Per

[Jonas Ådahl]

En ideal lösning borde vara att helt enkelt lägga till stöd för
externa repos, utan versionskontroll. Det är väl dock endast en vettig
lösning för vissa sorters projekt. Har sett kritik om sådan här sorts
setup (riktat åt subversions "externals"), men tror dock det vore en
bra feature till git, dessutom rätt enkel att lägga till (?).

[igno]

Jag kanske inte är tillräckligt insatt, men varför skulle man inte
bara kunna göra en branch av sin bleeding-edge kod? Då är det väl bara
att pull:a ut sin bleeding-edge branch för att testa bar med den nya
koden? Känns som jag missat något elementärt här...

/Erik

[Per Andersson]

2010/5/14 igno <er...@jutemar.se>:

> Jag kanske inte är tillräckligt insatt, men varför skulle man inte
> bara kunna göra en branch av sin bleeding-edge kod? Då är det väl bara
> att pull:a ut sin bleeding-edge branch för att testa bar med den nya
> koden? Känns som jag missat något elementärt här...

All kod i ditt repo kanske inte är relaterad till dina grejer. Tänk
dig att du har
en version av ett lib som du inkluderar som en git submodule.

T ex att du gör en web-app med något ramverk och har ramverket, som är
extern kod, som en git submodule.

Att ha stable/development-grenar är inte riktigt relaterat till
ramverket i det fallet.
Visst, du kan testa din development-gren med ramverket men du måste
uppdatera ramverkets submodule manuellt.


-- Per