U prethodnom postu u serijalu o korištenju distrbuiranih sustava za verzioniranje projekata pokazao sam osnove korištenja git-a, ali se nisam dotaknuo zanimljivih dijelova kod kojih distribuirani sustavi pokazuju svoju pravu stranu – grananje projekata u različite verzije, spajanje verzija nazad u jednu i repozicioniranje pojedinih grana u odnosu na druge grane (rebasing).

Ovi pojmovi koriste se u većini (svim?) distribuiranim SCM sustavima, ali se ovdje situacija već dovoljno komplicira da različiti sustavi na ne posve identične načine pristupaju istom problemu. Zbog toga je ovaj post posve specifičan i priča o git-u. Ukoliko koristite neki drugi SCM, imajte na umu da je stvar slična, ali se pojedinosti vjerojatno podosta razlikuju.

Grananje (branch)

U našem hello world projektu zasad imamo samo jednu granu, master, na kojoj smo radili sve promjene. To nam je odgovaralo jer smo točno znali što želimo napraviti slijedeće i nismo imali potrebe raditi više stvari paralelno (ili eksperimentirati u više različitih smjerova odjednom).

No, sada bismo željeli početi pisati i dokumentaciju za projekt. Kako nam se promjene vezane uz dokumentaciju ne bi mješale sa eventualnim nevezanim promjenama koda koje ćemo možda htjeti raditi, dokumentaciju ćemo dodavati u posebnoj grani projekta koju ćemo na kraju spojiti u glavnu. Kreirajmo novu granu doc iz postojeće master grane i odmah se prebacimo u nju:

> git checkout -b doc master
Switched to a new branch 'doc'

Za početak ćemo samo kreirati datoteku README.txt i u nju staviti osnovnu informaciju o programu:

Ovo je tipični "Hello World" program pisan u C-u.

Dodajmo datoteku u repozitorij, napravimo commit, i pogledajmo što smo dobili:

> git add README.txt
> git commit -m "dodan README"
[doc 7bb37b0] dodan README
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 README.txt
> git log
commit 7bb37b04d7eeb36dc91e60ef1d01e2648bb2e813
Author: Senko Rasic 
Date:   Sat Jan 23 06:06:26 2010 +0100
dodan README

commit 459b8bd04f3667425705d29f2c3a10bb45e79f5c
Author: Senko Rasic <senko@localhost>
Date:   Fri Dec 11 00:53:32 2009 +0100
malo uljepsano

commit ac3a48559de3b7f225ffa96c504a8586057fb4b9
Author: Senko Rasic <senko@localhost>
Date:   Fri Dec 11 00:38:16 2009 +0100
prva verzija

Kako smo granu doc stvorili iz grane master, ona je uključuje sve dosadašnje promjene. Ovaj prikaz nam nije previše koristan ukoliko želimo vidjeti samo razliku između trenutne grane i mastera. To možemo napraviti ovako:

> git log master..HEAD
commit 7bb37b04d7eeb36dc91e60ef1d01e2648bb2e813
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 06:06:26 2010 +0100
dodan README

Argumentom master..HEAD zatražili smo log svih promjena do zadnjeg commita u trenutnoj grani (HEAD) koje se ne nalaze u master grani. Osim od-do, parametar može biti i samo jedna oznaka, čime se traži log svih promjena od početka do te oznake. Tako će git log master prikazati log svih promjena na grani master bez obzira u kojoj smo grani trenutno. Oznaka HEAD uvijek pokazuje na posljednji commit u trenutnoj grani, pa je git log HEAD isto što i samo git log.

Dokumentiranje našeg programa dobro napreduje, ali paralelno s tim sjetili smo se da bi htjeli napraviti još neke kozmetičke promjene na programu. Na njima želimo raditi nezavisno o procesu dokumentiranja pa ćemo kreirati novu granu. Kako ne bi imali poluzavršenu dokumentaciju u novoj grani, novu granu beauty ćemo opet kreirati iz master grane:

> git checkout -b beauty master
Switched to a new branch 'beauty'

Trenutna inačica programa nije posve legalan C program, stoga ćemo je opet malo doraditi, tj. preraditi u nešto pristojnije:

#include <stdio.h>

int main(void)
{
  printf("Hello world\n");
  return 0;
}

Promjene spremimo u novi commit sa opisom “popravljen kod”. (Update: dodao nedostajući korak, commitanje upravo napravljenih promjena; hvala Mariju Splivalu na dojavi greške).

> git commit -a -m "popravljen kod"

Sada smo već napravili nekoliko grana i u svakoj po nekoliko commitova i sve je teže pratiti gdje se nalazi što. Podsjetimo se koje grane imamo i što one sadrže:

> git branch
* beauty
  doc
  master
> git log master..beauty
commit 5e547517e1a29a08b3594f6b8c8c0a289070376d
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 06:31:05 2010 +0100
popravljen kod

> git log master..doc
...
> git log master
...

Spajanje grana (merge)

Nakon što smo napravili sve što smo htjeli i sve committali te nakon što smo zaključili da smo zadovoljni promjenama na ovoj grani, željeli bismo je spojiti nazad u master.

Napomena: radi jednostavnosti primjera, ovdje nam se grana sastoji od samo jednog commita te ćemo je odmah spojiti nazad, što izgleda kao puno kompliciranja nizašto. No u stvarnom radu promjene obično nisu ovako trivijalne i grane se sastoje od nekoliko (možda desetke) committova, kod čega branch/merge ima smisla.

> git checkout master
Switched to branch 'master'
> git merge beauty
Updating 459b8bd..5e54751
Fast-forward
 hello.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

Prilikom ovog mergea, master nije imao nikakvih dodatnih commitova kojih nema u beauty grani pa se git nije morao mnogo mučiti sa spajanjem – samo je napravio fast-forward odnosno zalijepio sve nove commitove iz beauty grane u master granu. Pomoću git log možemo se uvjeriti da se uistinu radi o istim committovima (jedinstveni ID im je jednak).

Spajanjem grana beauty nije nestala. Ona još uvijek postoji, iako sad kad su svi njeni commitovi i u masteru, nema razlike između nje i mastera – jednako kao da smo je tek sad kreirali. U daljnjem radu opet možemo koristiti istu granu i dodavati nove committove koje periodički spajamo nazad u master. Stvar je izbora (i specifične organizacije projekta na kojem radite) želite li imati dugotrajnije grane koje periodički spajate s masterom ili za nove promjene radite nove grane.

Ukoliko odlučimo da nam grana više ne treba, možemo je obrisati:

> git branch -d beauty
Deleted branch beauty (was 5e54751).

Repozicioniranje grana (rebase)

Sretni sa dosadašnjim napretkom na master grani, vraćamo se nazad na doc. No sada master ima neke comitove koje doc nema. Zasad nema problema, git bi comittove pametno spojio, no ukoliko i ubuduće mijenjamo master (tj. dodajemo nove comitove), razlika će se sve više povećavati i sve će veća biti vjerojatnost da (slučajno ili namjerno) negdje modificiramo istu stvar i uzrokujemo konflikt.

Kako bi to minimizirali, dugovječne grane možemo repozicionirati, tj. rebazirati (rebase). Rebaziranjem pomičemo točku u kojoj se grana “odvojila” od grane iz koje smo je stvorili (ovdje, mastera), tako da izgleda kao da smo je tek sada stvorili.

> git checkout doc
Switched to branch 'doc'
> git rebase master
First, rewinding head to replay your work on top of it...
Applying: dodan README

> git log
commit 6c0516dbe782173b57997039576e3b38bc20997c
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 06:06:26 2010 +0100
dodan README

commit 5e547517e1a29a08b3594f6b8c8c0a289070376d
Author: Senko Rasic <senko@localhost>
Date:   Sat Jan 23 06:31:05 2010 +0100
popravljen kod

Primjetite da je nakon rebaziranja “dodan README” comit ispao zadnji, iako je zadnja promjena koju smo mi stvarno na cijelom projektu napravili bio “popravljen kod” u beauty grani. Također, primjetite da se ID zadnjeg comitta promjenio – to zapravo više nije isti commit. Radi se o tome da je git doslovno pospremio patcheve, obrisao comittove, a kasnije ih vraćao jedan po jedan i automatski radio nove comittove.

Kao rezultat toga, grana doc više uopće ne izgleda isto. Ako solo radite na projektu, to za vas ne igra nikakvu ulogu. Ali ukoliko nekoliko ljudi radi na istom projektu, potreban je oprez – ukoliko je netko kod sebe povukao vašu granu, a vi ju naknadno rebazirate, stanje comittova u toj grani u vašem repozitoriju više se neće slagati sa stanjem u njihovom repozitoriju. Kod takvih situacija osnovno pravilo je – nikad ne modificirajte povijest grane koju je netko drugi već povukao od vas.

Merge ili rebase?

Nije odmah očito zašto bi radili rebase ako već imamo spajanje grana, no postoji razlika. Kod spajanja promjene iz druge grane “naljepe” se na trenutnu granu. Ukoliko dođe do konflikta, nemamo informaciju koji od comitova iz trenutne grane je uzrokovao konflikt. Stoga ga nećemo moći niti prepraviti, nego ćemo rješenje konflikta samo zalijepiti kao još jedan novi commit.

Spajanje logički znači “sav dosadašnji rad na grani koja se spaja sa trenutnom granom od sada se nalazi i u ovoj grani”. Ukoliko bismo koristili merge za povlačenje novih promjena mastera u doc, efekt bi bio kao da smo rekli “ok, od sada će nam doc biti glavna grana u projektu”.

Za razliku od toga, repozicioniranje znači “promjeni trenutnu granu tako da izgleda da sam sve promjene radio nad sadašnjim sadržajem mastera (odnosno granom nad kojom radim rebase – baznu granu)”, odnosno svojevrsno “osvježavanje patcheva” koje imamo u odnosu na master. Konkretno, rebase radi slijedeće:

1. privremeno miče sve comittove iz trenutne grane koji nisu u baznoj grani i sprema ih na sigurno
2. povlači sve nove comittove iz bazne grane koji nisu u trenutnoj (fast-forward), nakon čega bazna grana i trenutna grana imaju isti sadržaj
3. jedan po jedan vraća nazad comittove koji su spremljeni na sigurno

Ukoliko u nekom trenu dođe do konflikta, rebase će se zaustaviti i imat ćemo priliku prepraviti commit koji uzrokuje konflikt. Na taj način praktički “osvježavamo” trenutnu granu, tako da promjene koja ona predstavlja budu primjenjive na trenutno stanje bazne grane. Ovo nam omogućuje da imamo dugovječne grane sa relativno velikim promjenama u odnosu na baznu granu, a da te promjene uvjek budu ažurne.

Kada koristiti rebase ili merge možete pročitati i u Linusovom mailu o toj temi na LKML – “Some git best practices” post na LWN sadrži malo šire objašnjenje za nas koji ne pratimo LKML.

Join us next time…

Rukovanje granama je vjerojatno najbitniji i najkompliciraniji dio git-a. Nakon što smo to apsolvirali, možemo se opet baciti na laganije, a opet korisne stvari koje korisnicima gita život čine ugodnijim i lakšim. Pridružite mi se slijedeći put dok istražujem interaktivno dodavanje promjena, pretraživanje povijesti, tagiranje, cherry-picking, …

Ne znam koja će situacija biti jednom kad se N900 počne prodavati kod nas, ali ukoliko imate primjerak izvana, nemate hrvatsku tastaturu nego najvjerojatnije koristite englesku. Ako vam kojim slučajem zatrebaju naši dijakritici (recimo prilikom pisanja službenog maila :), dovest ćete se u neprilike.

Jedno jednostavno rješenje je nadodati naše dijakritike na kombinacije Fn + kursorske tipke, na kojima po defaultu nema nikakvih drugih simbola. Kako naših dijakritika ima 5, osim kursorskih tipki možemo se poslužiti i BackSpace tipkom.

Kako bi layout bio što sličniji onom na normalnim tipkovnicama, na svojoj Nokii postavio sam ga tako da mi Fn+Up bude Š, Fn+BackSpace Đ (malo poetske pravde je u tome da je davno prije BackSlash bio Đ :), Fn+Left Č, Fn+Down Ć, Fn+Right Ž.

Kako biste to napraivli i kod sebe, morate biti u shellu i imati root privilegije, za što vam pomoći programčić zvan gainroot. Napomena: ovim lako možete dovesti svoju N900 u stanje da se ne može bootati, stoga budite pažljivi, ne radite ovo ako niste sigurni šta radite; ne odgovaram za bilo kakve nastale probleme.

Remapiranje tipkovnice radite editiranjem datoteke /usr/share/X11/xkb/symbols/nokia_vndr/rx-51. Prije editiranja datoteke, svakako napravite backup kopiju. Napomena: Backup kopiju nemojte spremati u isti direktorij, jer će vam se N900 odbiti bootati slijedeći put!

U datoteci pronađite liniju koja spominje <BKSP> (BackSpace tipka), i promijenite je u:

key <BKSP>   { type[Group1] = "PC_FN_LEVEL2", symbols[Group1] =
        [ BackSpace, dstroke ] };

Nakon toga na samom dnu datoteke pronađite blok xkb_symbols "arrows_4btns" i promijenite ga u (odlazak u novi red nakon znaka “=” je tu samo zbog čitljivosti u blog postu – u datoteci možete svaku definiciju staviti u svoj red):

xkb_symbols "arrows_4btns" {
    key <UP>   { type[Group1] = "PC_FN_LEVEL2", symbols[Group1] =
        [ Up, scaron ] };
    key <LEFT> { type[Group1] = "PC_FN_LEVEL2", symbols[Group1] =
        [ Left, ccaron ] };
    key <DOWN> { type[Group1] = "PC_FN_LEVEL2", symbols[Group1] =
        [ Down, cacute ] };
    key <RIGHT> { type[Group1] = "PC_FN_LEVEL2", symbols[Group1] =
        [ Right, zcaron ] };
};

(Update: popravio nazive simbola, originalno sam krivo postavio uglate zagrade).

Spremite datoteku i isprobajte odmah novi layout naredbom setxkbmap. Ukoliko vam naredba vrati grešku, popravite datoteku ili vratite backup – nemojte niti slučajno ostaviti nepravilnu datoteku, jer će vam se kod slijedećeg boota N900 odbiti podići.

Update: ispravio pogrešno napisan naziv komande, hvala Saši na dojavi.

Nakon uspješnog učitavanja novog layouta, naši dijakritici odmah su vam dostupni u svim aplikacijama, koristeći kombinaciju Fn+kursorske tipke ili backspace, za mala slova, odnosno Shift+Fn+tipke za velika slova.

Inspiraciju i sve potrebne informacije za post našao sam na Maemo wikiju, gdje možete pronaći još informacija o ovome i mnogim drugim hackovima za vašu N900.

Update: pripremljenu datoteku možete preuzeti ovdje. Datoteku skopirajte na gorenavedenu i svakako provjerite na goreopisan način (meni provjereno radi, ali ne garantiram da će i vama i ne snosim posljedice ako bude problema).

U sezoni (političkih) izbora vrijeme je za moj tradicionalni izbor free & open source softvera kojeg koristim u svakodnevnom radu i zabavi na računalu. Kako je to izgledalo pred dvije godine pogledajte u ovom postu. A ove godine, krenimo redom:

Editor – (G)VIM

Uza sve moje pokušaje i isprobavanja drugih editora, uvijek se vraćam VIM-u (odnosno njegovom grafičkom pandanu GVIM-u). Većina piskaranja koje radim je zapravo programiranje, za što je ovaj editor upravo idealan. Još uvijek sam na newb razini, ali svake godine upamtim par zgodnih shortcutova .. za jedno 20tak godina ću biti guru :) Mali demo što sve VIM može (otprilike polovicu ovoga još ne koristim .. kao što rekoh, newb sam) pogledajte u izvrsnoj Perl.Hacks.On.Vim prezentaciji.

Web browser – Google Chrome

Velika promjena u zadnje dvije godine – većina browser opcija sada je bazirana na WebKit engineu, a jedino se Firefox drži svojeg Gecka. Novi rat browsera koji se zahuktava u poslijednje vrijeme osigurao je da svi browseri budu mnogo kvalitetniji nego njihove starije inačice – Firefox više nikako nije neosporni vlasnik Linux desktop browser mindsharea.

Pri najavi Google Chrome browsera bio sam prilično nezadovoljan overhypeom koji je dotični doživio. Nakon izlaska bete za Linux, prebacio sam se par dana na nju i mogu zadovoljno reći da Googlovci nisu podbacili – browser je stvarno kvalitetan. Nakon tjedan-dva testiranja, sve svoje browsanje prebacio sam na Chrome. Zasad mi se subjektivno čini stvarno brži od Firefoxa (3.5). Koliko je stvar u činjenici da je Firefox opterećen raznoraznim ekstenzijama i alatima (jeste li znali da Firebug usporava JavaScript čak i na stranicama gdje nije upaljen?) a koliko u stvarnoj brzini enginea i rendera, vidjet ću s vremenom kad se i na Chromeu nakupi po par ekstenzija.

Jedna stvar koja mi se kod Chromea sviđa za razliku od Firefoxa je jednostavnost pisanja ekstenzija – jednostavne ekstenzije se mogu napisati u par desetaka linija JS-a, za razliku od mnoštva boilerplatea kojeg treba pripremiti za Firefox.

Kao lagano off-topic zanimljivost, napomenuo bih da iako koristim Google Chrome kao browser, ne koristim Google kao tražilicu (niti GMail, niti Google Docs, … koristim GMaps kad mi zatreba te GTalk iz Empathya); umjesto toga, koristim DuckDuckGo! zbog toga što mi daje preglednije, relevantne rezultate, a njihov 0-click info box je u većini slučajeva točno ono što me i zanima. U par mjeseci korištenja mislim da nisam više od 2-3 puta zatražio drugu “stranicu” rezultata. Mana DuckDuckGoa su slabiji rezultati za .hr prostor i slabiji rezultati ukoliko copy-pasteam neki dugački opis greške; za te stvari i dalje ručno odem na Google.

Grafičko sučelje – XMonad

Pomalo je depresivno da današnja računala subjektivno ne djeluju mnogo brža od računala koje smo koristili pred 5 ili 10 godina. Naravno da objektivno jesu mnogo brža – dovoljno je samo usporediti grafiku sadašnjih i tadašnjih igara, ili sadašnje multimedijske mogućnosti sa tadašnjim playbackom poštanskih maraka ili kockastih filmova niske rezolucije. Sama GUI sučelja su mnogo rafiniranija, sa više opcija, efekata i slično. Ali opet, pomalo je to depresivno.

Isprobavši par alternativa, otkrio sam da mi je od laganih rješenja najzgodniji XMonad, window manager pisan u Haskellu (isprobavanje XMonada pogodilo se vremenski sa čitanjem izvrsne Real World Haskell knjige o tom programskom jeziku). XMonad mi se učinio stvarno user-friendly, mnogo više od awesome WM-a pisanog napola u Lui, iz jednostavnog razloga što sam za awesome morao odmah editirati konfiguracijsku datoteku (i učiti Luu) dok za XMonad još uvijek nemam nikakvu konfig datoteku – stvar radi po defaultu točno ono što želim.

Kad sam već maknuo Metacity, rješio sam se i GNOME panela, a kako niti Nautilus ne koristim često, izbacio sam i njega. Da izbjegnem pokretanje gnome-sessions-daemona samo zbog gnome-screensavera, zamjenio sam i njega xscreensaverom, a kad već idem u tom smjeru, i gdm sam zamjenio xdm-om.

Networking – male shell skripte

Izbacivši GNOME Panel ostao sam i bez Network Managera (cnetworkmanager, komandolinijski alat, nije pretjerano korisna stvar). Srećom, Nikola mi je otkrio wicd, zamjenu za NetworkManager sa dobrim grafičkim i terminal klijentima. No zbog nekih problema drivera wireless kartice na svom laptopu, kod resumea treba reinicijalizirati driver pa sam cijelu stvar automatizirao sa par shell skripta i otkrio da mi je i sam wicd nepotreban.

Terminal – GNOME Terminal

Kako na kraju ispada da većinu stvari radim / pokrećem iz komadndne linije, bitno mi je da je terminal emulator lagan i brz. Kao pobjednik pokazao mi se GNOME Terminal, jer iako nije lagan po potrošnji memorije i prvom startupu, najbrži je u prikazu antialiasinih TrueType fontova (a od Inconsolate se ne odvajam).

E-mail – Thunderbird 3

Thunderbird 3 pokazao mi se kao odličan mail klijent – osim vidljivih unapređenja u odnosu na verziju 2 (bolji i brži search, tabovi, tagiranje), pokazao mi se kao mnogo bolji u hendlanju velikih IMAP foldera s kojima svakodnevno radim.

Media centar – XBMC

Da sam ovaj post pisao pred 3 tjedna, pod ovu stavku stavio bih Moovidu (nee. Elisa), vrlo dobar media centar baziran na GStreamer frameworku. No Moovida mi zna imati problema sa nekim formatima (ponajviše .mkv) i updateom librarya, a pogotovo sa hendlanjem velike količine fajlova u mojoj glazbenoj kolekciji (zbog čega trenutno koristim i remote kontrolirani Music Player Daemon). XBMC ne pati od tih boljki, također ima podršku za pluginove te mi se zasad ukupno čini kao bolji sustav.

Chat – Empathy

Kako sam jedan od developera na Telepathy projektu (kojeg je i Empathy client jedan dio), nije nikakvo čudo da mi je Empathy najdraži IM client. No otkad imam N900, više chatam sa njega (opet pogonjeno Telepathyem) nego sa laptopa…

Twitter – Chromed Bird

Rudimentaran, ali ima sve što meni treba (pregled svog timelinea, reply, retweet, skraćivanje linkova putem bit.ly-a). Neko vrijeme sam koristio Thwirl i poslije Gwibber, ali prvi mora učitati popriličan AIR runtime a drugi WebKit. Za razliku od njih, Chromed Bird nema praktički nikakvi dodatni load na sustav.