Chapters ▾ 2nd Edition

5.3 Distribuerat Git - Förvalta ett projekt

Förvalta ett projekt

Förutom att veta hur du bidrar effektivt till ett projekt behöver du troligen också veta hur man förvaltar ett. Det kan innebära att acceptera och tillämpa ändringspatchar som genererats via format-patch och skickats till dig via e-post, eller att integrera ändringar i fjärrgrenar. Oavsett om du förvaltar ett huvudkodförråd eller vill hjälpa till med att granska och godkänna bidrag behöver du veta hur du tar emot arbete på ett sätt som är tydligt för andra och hållbart för dig på sikt.

Arbeta i ämnesgrenar

När du ska integrera nytt arbete är det i regel en bra idé att prova det i en ämnesgren – en tillfällig gren som skapats för att testa det nya arbetet. Det gör det enkelt att justera en ändringspatch och lämna det om det inte fungerar, tills du har tid att återvända. Om du skapar ett enkelt grennamn baserat på temat, till exempel ruby_client, är det lätt att hitta tillbaka senare. Förvaltarna av Git använder ofta en namnrymd också, till exempel sc/ruby_client, där sc är initialerna för den som bidrog. Som du minns kan du skapa grenen från master så här:

$ git branch sc/ruby_client master

Om du vill byta till den direkt använder du checkout -b:

$ git checkout -b sc/ruby_client master

Nu är du redo att lägga in det inskickade arbetet i ämnesgrenen och avgöra om du vill sammanfoga det till dina långlivade grenar.

Arbeta via e-post

Om du tar emot en ändringspatch via e-post som ska in i projektet behöver du applicera den i din ämnesgren för att kunna granska den. Det finns två sätt att applicera en e-postad ändringspatch: git apply eller git am.

Applicera en e-postad ändringspatch med apply

Om du har fått en ändringspatch av någon som genererat den med git diff eller någon variant av Unix diff (rekommenderas inte; se nästa avsnitt), kan du applicera den med git apply. Om vi antar att du sparade ändringspatchen i /tmp/patch-ruby-client.patch ser det ut så här:

$ git apply /tmp/patch-ruby-client.patch

Kommandot ändrar filerna i din arbetskatalog. Det är nästan identiskt med att köra patch -p1, men är mer konservativt och accepterar färre luddiga matchningar än patch. Det hanterar också filer som läggs till, tas bort och döps om när de beskrivs i git diff-format, vilket patch inte gör. Slutligen är git apply ett "applicera allt eller avbryt allt"-läge, där allt eller inget appliceras, medan patch kan applicera delar och lämna arbetskatalogen i ett märkligt läge. git apply är alltså mer konservativt än patch. Det skapar ingen incheckning åt dig – efteråt måste du köa och checka in ändringarna manuellt.

Du kan också använda git apply för att kontrollera om en ändringspatch kan appliceras rent innan du försöker, genom git apply --check:

$ git apply --check 0001-see-if-this-helps-the-gem.patch
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply

Om det inte finns någon utdata kan ändringspatchen tillämpas utan problem. Kommandot avslutar med ett icke-nollvärde om kontrollen misslyckas, vilket gör det användbart i skript.

Applicera en e-postad ändringspatch med am

Om bidragslämnaren är en van Git‑användare och använde format-patch blir jobbet enklare, eftersom ändringspatchen innehåller författarinformation och incheckningsmeddelande. Uppmuntra gärna bidragslämnare att använda format-patch i stället för diff. git apply bör främst användas för äldre ändringspatchar.

För att applicera en ändringspatch som genererats av format-patch använder du git am (namnet kommer av "tillämpa en serie ändringspatchar från en brevlåda"). Tekniskt sett är git am byggt för att läsa en mbox-fil, som är ett enkelt textformat för att lagra ett eller flera e-postmeddelanden i en fil. Det ser ut så här:

From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
From: Jessica Smith <jessica@example.com>
Date: Sun, 6 Apr 2008 10:17:23 -0700
Subject: [PATCH 1/2] Add limit to log function

Limit log functionality to the first 20

Det här är början på utdata från git format-patch som du såg i föregående avsnitt; det är också ett giltigt mbox-format. Om någon skickar ändringspatchen till dig korrekt med git send-email och du laddar ner den i mbox-format kan du peka git am till mbox-filen så applicerar den alla ändringspatchar den hittar. Om din e-postklient kan spara flera e-postmeddelanden som mbox kan du spara hela serien i en fil och sedan köra git am för att applicera dem en och en.

Om någon i stället laddar upp en ändringspatchfil som genererats med git format-patch till ett ärendehanteringssystem kan du spara filen lokalt och köra git am på den:

$ git am 0001-limit-log-function.patch
Applying: Add limit to log function

Du ser att det applicerades rent och att en ny incheckning skapades åt dig. Författarinformationen tas från e-postmeddelandets Från- och Datum-rubriker, och incheckningsmeddelandet tas från Ämne och brödtexten (före ändringspatchen). Om ändringspatchen applicerades från mbox-exemplet ovan skulle incheckningen se ut ungefär så här:

$ git log --pretty=fuller -1
commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
Author:     Jessica Smith <jessica@example.com>
AuthorDate: Sun Apr 6 10:17:23 2008 -0700
Commit:     Scott Chacon <schacon@gmail.com>
CommitDate: Thu Apr 9 09:19:06 2009 -0700

   Add limit to log function

   Limit log functionality to the first 20

Incheckningsinformationen visar vem som applicerade ändringspatchen och när. Författarinformationen anger vem som skapade det och när.

Det händer att ändringspatchen inte kan appliceras på grund av konflikter. Kanske har din huvudgren divergerat för långt från den gren som ändringspatchen byggdes på, eller så grenades den från en ändringspatch som du inte har applicerat än. git am misslyckas då och frågar hur du vill lösa konflikten:

$ git am 0001-see-if-this-helps-the-gem.patch
Applying: See if this helps the gem
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply
Patch failed at 0001.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".

Kommandot anger vilka filer som har konflikter, precis som vid sammanslagning eller ombasering. Du löser det på samma sätt – redigerar filen, köar den och kör git am --resolved för att fortsätta:

$ (fix the file)
$ git add ticgit.gemspec
$ git am --resolved
Applying: See if this helps the gem

Om du vill att Git ska försöka göra en mer intelligent konfliktlösning kan du lägga till -3. Git försöker då göra en trefältsfusion. Det fungerar inte om den incheckning som ändringspatchen grenades från inte finns i ditt kodförråd. Om ändringspatchen däremot grenades från en offentlig incheckning är -3 ofta mycket effektivt:

$ git am -3 0001-see-if-this-helps-the-gem.patch
Applying: See if this helps the gem
error: patch failed: ticgit.gemspec:1
error: ticgit.gemspec: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.

Utan -3 skulle ändringspatchen i det här fallet ha betraktats som konfliktfylld. Med -3 appliceras den utan problem.

Om du applicerar många ändringspatchar från en mbox kan du också köra am interaktivt, vilket stannar vid varje ändringspatch och frågar om du vill applicera den:

$ git am -3 -i mbox
Commit Body is:
--------------------------
See if this helps the gem
--------------------------
Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all

Det är användbart om du har många ändringspatchar och vill titta på dem innan du applicerar, eller hoppa över någon du redan har lagt till.

När alla ändringspatchar har lagts till och checkats in i din gren behöver du bestämma om och hur du ska integrera dem i en långlivad gren.

Checka ut fjärrgrenar

Om ett bidrag kommer från en Git‑användare som har växlat till sin egen gren, skickat ett antal ändringar till den och sedan skickat URL:en till sitt kodförråd och namnet på grenen kan du lägga till det som fjärrkodförråd och växla till den lokalt.

Om Jessica till exempel skickar ett e-postmeddelande och skriver att hon har en bra funktion i ruby-client-grenen i sitt kodförråd, kan du testa den genom att lägga till hennes kodförråd som fjärrkodförråd och växla till grenen lokalt:

$ git remote add jessica git://github.com/jessica/myproject.git
$ git fetch jessica
$ git checkout -b rubyclient jessica/ruby-client

Om hon skickar e-post till dig igen med en annan gren kan du direkt köra fetch och checkout eftersom fjärrkodförrådet redan finns.

Det här är mest användbart om du arbetar regelbundet med en person. Om någon bara bidrar med en ändringspatch ibland är det mindre arbete att acceptera den via e-post än att kräva egna servrar och hela tiden lägga till och ta bort fjärrkodförråd. Du vill sannolikt inte heller ha hundratals fjärrgrenar där de flesta bara innehåller en eller två ändringspatchar. Skript och värdtjänster kan dock göra det enklare – mycket beror på hur du och dina bidragslämnare jobbar.

En annan fördel är att du behåller incheckningshistoriken. Även om det finns sammanslagningskonflikter vet du var i historiken arbetet är baserat; en korrekt trefältsfusion är standard i stället för att behöva ange -3 och hoppas att ändringspatchen genererades från en offentlig incheckning.

Om du inte samarbetar kontinuerligt med en person men ändå vill dra in kod på det här sättet kan du ange URL:en direkt när du kör git pull. Det gör en engångsuppdatering utan att spara URL:en som en fjärrreferens:

$ git pull https://github.com/onetimeguy/project
From https://github.com/onetimeguy/project
 * branch            HEAD       -> FETCH_HEAD
Merge made by the 'recursive' strategy.

Avgöra vad som ska integreras

Nu har du en ämnesgren som innehåller ett bidrag. Du behöver bestämma vad du vill göra med den. I det här avsnittet går vi igenom några kommandon som hjälper dig att granska exakt vad som kommer att tillämpas om du sammanfogar grenen med din huvudgren.

Det är ofta användbart att få en överblick över alla incheckningar i grenen som inte finns i huvudgrenen. Du kan utesluta incheckningar i huvudgrenen genom att lägga till --not före grennamnet. Det gör samma sak som master..contrib. Om din bidragslämnare skickar två ändringspatchar, du skapar en gren som heter contrib och applicerar dem där kan du köra:

$ git log contrib --not master
commit 5b6235bd297351589efc4d73316f0a68d484f118
Author: Scott Chacon <schacon@gmail.com>
Date:   Fri Oct 24 09:53:59 2008 -0700

    See if this helps the gem

commit 7482e0d16d04bea79d0dba8988cc78df655f16a0
Author: Scott Chacon <schacon@gmail.com>
Date:   Mon Oct 22 19:38:36 2008 -0700

    Update gemspec to hopefully work better

För att se vad varje incheckning gör kan du ange -p till git log. Då läggs diffen till, alltså ändringsmängden.

För att se en fullständig diff över vad som skulle hända om du sammanfogar hela ämnesgrenen med en annan gren kan du behöva använda ett knep för att få korrekta resultat. Du kanske tror att du kan köra:

$ git diff master

Det ger dig en diff, men om din master-gren har flyttats framåt sedan du grenade ämnesgrenen blir den missvisande. Det beror på att Git direkt jämför ögonblicksbilden av den sista incheckningen i ämnesgrenen med ögonblicksbilden av den senaste incheckningen i master. Om du till exempel har lagt till en rad i en fil på master ser det ut som om ämnesgrenen tar bort den.

Om master-grenen inte har rört sig är det inget problem, men om historiken divergerat ser diffen ut som att du lägger till allt nytt och tar bort allt unikt för master.

Det du egentligen vill se är ändringarna som lagts till i ämnesgrenen – alltså skillnaden mellan ämnesgrenens spets och dess gemensamma föregångare med master.

Tekniskt sett kan du göra det genom att räkna ut den gemensamma föregångaren och sedan köra diff:

$ git merge-base contrib master
36c7dba2c95e6bbb78dfa822519ecfec6e1ca649
$ git diff 36c7db

Eller kortare:

$ git diff $(git merge-base contrib master)

Ingen av dessa varianter är särskilt bekväm, så Git erbjuder en kortform: trepunktssyntaxen. I git diff kan du skriva tre punkter efter en annan gren för att jämföra den sista incheckningen på din gren med den gemensamma föregångaren:

$ git diff master...contrib

Det visar exakt vad som lagts till i grenen sedan den delade föregångaren med master. Det är en mycket användbar syntax att lägga på minnet.

Integrera kod från bidragslämnare

När arbetet i ämnesgrenen är redo att sammanfogas i huvudgrenen är frågan hur du ska göra det. Dessutom: vilket övergripande arbetsflöde vill du använda för att förvalta projektet? Du har flera metoder, och vi går igenom några.

Arbetsflöden med sammanslagning

Ett grundläggande arbetsflöde är att helt enkelt sammanfoga allt arbete direkt i master. Du har en master-gren med stabil kod. När du har arbete i en ämnesgren som du tror är klart, eller arbete som någon annan bidragit med och du har verifierat, sammanfogar du det i master, tar bort den sammanfogade ämnesgrenen och upprepar.

Om vi har ett kodförråd med arbete i två grenar som heter ruby_client och php_client som ser ut som Historik med flera funktionsgrenar, och vi sammanfogar ruby_client följt av php_client, blir historiken som i Efter en sammanslagning med en funktionsgren.

Historik med flera funktionsgrenar.
Figur 70. Historik med flera funktionsgrenar
Efter en sammanslagning med en funktionsgren.
Figur 71. Efter en sammanslagning med en funktionsgren

Det här är kanske det enklaste arbetsflödet, men i större eller stabilare projekt kan det bli problematiskt om du behöver vara mer selektiv med vad du tar in.

Om du har ett viktigare projekt kanske du vill använda en tvåfas-sammanslagning. Då har du två långlivade grenar, master och develop, där master uppdateras först när en mycket stabil version skapas och all ny kod integreras i develop. Du skickar upp båda dessa grenar till det publika kodförrådet. När du har en ny funktionsgren att sammanfoga (Före en sammanslagning av en funktionsgren), sammanfogar du den i develop (Efter en sammanslagning av en funktionsgren); när du taggar en version snabbspolar du master till den punkt där develop är stabil (Efter en ny utgåva).

Före en sammanslagning av en funktionsgren.
Figur 72. Före en sammanslagning av en funktionsgren
Efter en sammanslagning av en funktionsgren.
Figur 73. Efter en sammanslagning av en funktionsgren
Efter en ny utgåva.
Figur 74. Efter en ny utgåva

På så vis kan de som klonar ditt kodförråd välja att växla till master för den senaste stabila utgåvan, eller develop för det mer föränderliga innehållet. Du kan också utöka konceptet med en integrate-gren där allt arbete sammanfogas. När den grenen är stabil och testerna går igenom sammanfogar du den i develop; när den har varit stabil ett tag snabbspolar du master.

Arbetsflöde med stora sammanslagningar

Git‑projektet har fyra långlivade grenar: master, next och pu (föreslagna uppdateringar) för nytt arbete, och maint för underhållsbackportar. När nytt arbete introduceras samlas det i ämnesgrenar i förvaltarens kodförråd, likt det vi beskrev (se Hantera en komplex serie med parallella ämnesgrenar). Vid det här laget utvärderas ämnena för att avgöra om de är säkra och redo eller om de behöver mer arbete. Om de är säkra sammanfogas de i next, och den grenen skickas upp så att alla kan prova ämnena tillsammans.

Hantera en komplex serie med parallella ämnesgrenar.
Figur 75. Hantera en komplex serie med parallella ämnesgrenar

Om det behövs mer arbete på en ämnesgren sammanfogas den i pu i stället. När de är helt stabila sammanfogas de i master. next och pu byggs sedan om från master. Det innebär att master nästan alltid rör sig framåt, next ombaseras ibland och pu ombaseras ännu oftare:

Sammanfoga ämnesgrenar med långlivade integrationsgrenar.
Figur 76. Sammanfoga ämnesgrenar med långlivade integrationsgrenar

När en ämnesgren till sist har sammanfogats med master tas den bort från kodförrådet. Git‑projektet har också en maint-gren som utgår från den senaste utgåvan för att tillhandahålla bakåtkompatibla ändringspatchar om en underhållsutgåva behövs. När du klonar Git‑kodförrådet får du alltså fyra grenar som du kan växla till för att utvärdera projektet i olika stadier beroende på hur nyskapande du vill vara eller hur du vill bidra; och förvaltaren har ett strukturerat arbetsflöde för att granska nya bidrag. Git‑projektet har ett specialiserat arbetsflöde. För att förstå det bättre kan du läsa mer på Git‑förvaltarens guide.

Arbetsflöden med ombasering och handplockning

När du har arbete i en ämnesgren och har bestämt att du vill integrera det kan du göra det på två sätt: ombasera eller handplocka. Vissa förvaltare föredrar att ombasera eller handplocka för att hålla en mestadels linjär historik. När du har arbete i en ämnesgren och vill integrera det byter du till den grenen och kör ombasering för att bygga om ändringarna ovanpå din master (eller develop, och så vidare). Om det går bra kan du snabbspola master. I slutänden får du en linjär historik.

Ett annat sätt att föra in arbete från en gren till en annan är att handplocka. Att handplocka i Git är som ombasering men för en enskild incheckning. Det tar en ändringspatch från en incheckning och försöker applicera den på den gren du är på. Det är användbart om du har flera incheckningar på en ämnesgren men bara vill integrera en av dem, eller om du vill ta in incheckningar en och en i stället för att ombasera. Om du till exempel har ett projekt som ser ut så här:

Exempelhistorik före handplockning.
Figur 77. Exempelhistorik före handplockning

Om du vill dra in incheckningen e43a6 i master kan du köra:

$ git cherry-pick e43a6
Finished one cherry-pick.
[master]: created a0a41a9: "More friendly message when locking the index fails."
 3 files changed, 17 insertions(+), 3 deletions(-)

Det här drar in ändringarna från e43a6 i master, men du får ett nytt SHA-1 eftersom datumet för tillämpningen är annorlunda. Historiken ser nu ut så här:

Historik efter handplockning av en incheckning från en funktionsgren.
Figur 78. Historik efter handplockning av en incheckning från en funktionsgren

Nu kan du radera din funktionsgren och släppa incheckningarna som du inte vill få in.

Rerere

Om du gör många sammanslagningar och ombaseringar, eller om du förvaltar en långlivad funktionsgren, har Git en funktion som heter "rerere" som kan vara användbar.

Rerere betyder ungefär "återanvänd sparad lösning" – det är ett sätt att korta ned manuell konflikthantering. När rerere är aktiverat sparar Git en uppsättning före- och efterbilder från lyckade sammanslagningar, och om den ser en konflikt som ser likadan ut som en du redan har löst använder Git den lösningen utan att störa dig.

Funktionen har två delar: en konfigurationsinställning och ett kommando. Inställningen heter rerere.enabled, och den är tillräckligt användbar för att lägga in i din globala konfiguration:

$ git config --global rerere.enabled true

När du löser en sammanslagning med konflikter sparas lösningen i mellanlagringen om den behövs i framtiden.

Om du behöver kan du interagera med rerere‑mellanlagringen med kommandot git rerere. När det används ensamt kontrollerar Git databasen med lösningar och försöker hitta en matchning med aktuella konflikter och lösa dem (det görs automatiskt om rerere.enabled är true). Det finns även underkommandon för att se vad som sparas, radera specifika lösningar eller rensa hela mellanlagringen. Vi går in på rerere mer i detalj i Rerere.

Versionsmarkeringar

När du har bestämt dig för att publicera en ny utgåva av ditt projekt vill du troligen sätta en tagg så att du kan återskapa den versionen när som helst. Du kan skapa en ny tagg som vi diskuterade i Grunderna i Git. Om du som förvaltare vill signera taggen ser det ut så här:

$ git tag -s v1.5 -m 'my signed 1.5 tag'
You need a passphrase to unlock the secret key for
user: "Scott Chacon <schacon@gmail.com>"
1024-bit DSA key, ID F721C45A, created 2009-02-09

Om du signerar taggar kan du få problem med att distribuera den publika PGP-nyckeln som används för att signera taggarna. Git‑projektets förvaltare löste detta genom att lägga in sin publika nyckel som en blob i kodförrådet och sedan lägga en tagg som pekar direkt på innehållet. För att göra detta kan du ta reda på vilken nyckel du vill använda genom att köra gpg --list-keys:

$ gpg --list-keys
/Users/schacon/.gnupg/pubring.gpg
---------------------------------
pub   1024D/F721C45A 2009-02-09 [expires: 2010-02-09]
uid                  Scott Chacon <schacon@gmail.com>
sub   2048g/45D02282 2009-02-09 [expires: 2010-02-09]

Du kan importera nyckeln direkt i Git‑databasen genom att exportera den och skicka den genom git hash-object, som skriver en ny blob med innehållet och ger dig tillbaka SHA-1 för blobben:

$ gpg -a --export F721C45A | git hash-object -w --stdin
659ef797d181633c87ec71ac3f9ba29fe5775b92

När du har innehållet i din nyckel i Git kan du skapa en tagg som pekar direkt på den genom att ange SHA-1-värdet från hash-object:

$ git tag -a maintainer-pgp-pub 659ef797d181633c87ec71ac3f9ba29fe5775b92

Med kommandot git push --tags kan du dela taggen maintainer-pgp-pub med alla. Om någon vill verifiera en tagg kan de importera din PGP-nyckel genom att dra ut blobben direkt ur databasen och importera den i GPG:

$ git show maintainer-pgp-pub | gpg --import

De kan också använda nyckeln för att verifiera dina signerade taggar. Om du dessutom inkluderar instruktioner i taggmeddelandet kan körning av git show <tagg> ge slutanvändaren mer detaljer om taggverifiering.

Generera versionsnummer

I Git finns det inget inbyggt sätt att generera löpande versionsnummer som "v123" för varje incheckning. Om du vill ha ett versionsnummer som människor kan tolka för varje incheckning kan du köra git describe på incheckningen. Git genererar då en sträng som består av namnet på den senaste taggen före incheckningen, följt av antalet incheckningar sedan den taggen, följt av en del av SHA-1-värdet för incheckningen (föregånget av bokstaven "g" som betyder Git):

$ git describe master
v1.6.2-rc1-20-g8c5b85c

På det här sättet får du en sträng som är meningsfull för människor att använda som versionsnummer. Om du bygger Git från källkoden klonad från Git‑kodförrådet ger git --version dig något som ser ut så här. Om du beskriver en incheckning som du direkt har taggat ger det dig bara taggnamnet.

git describe kräver annoterade taggar som standard (taggar som skapats med -a eller -s); om du vill dra nytta av lättviktiga taggar också lägger du till --tags. Du kan också använda strängen som mål för git checkout eller git show, även om det förlitar sig på det förkortade SHA-1-värdet i slutet, vilket kanske inte är giltigt för alltid. Till exempel hoppade Linux-kärnan nyligen från 8 till 10 tecken för att säkerställa SHA-1-objektens unicitet, så äldre git describe-utdata ogiltigförklarades.

Förbereda en utgåva

Nu vill du publicera en ny utgåva. En av de saker du vill göra är att skapa ett arkiv av den senaste ögonblicksbilden av din kod för dem som inte använder Git. Kommandot för att göra detta är git archive:

$ git archive master --prefix='project/' | gzip > `git describe master`.tar.gz
$ ls *.tar.gz
v1.6.2-rc1-20-g8c5b85c.tar.gz

Om någon öppnar arkivet får de den senaste ögonblicksbilden av projektet i en projektkatalog. Du kan också skapa ett zip-arkiv på liknande sätt genom att ange --format=zip:

$ git archive master --prefix='project/' --format=zip > `git describe master`.zip

Nu har du ett tar-arkiv och ett zip-arkiv av utgåvan som du kan ladda upp till din webbplats eller skicka via e-post till folk.

Kortlogg

Det är dags att skicka e-post till din e-postlista med personer som vill veta vad som händer i ditt projekt. Ett trevligt sätt att snabbt få en ändringslogg över vad som lagts till sedan senaste utgåvan eller senaste e-postmeddelandet är att använda git shortlog. Det sammanfattar alla incheckningar i intervallet du anger; till exempel ger följande en sammanfattning av alla incheckningar sedan ditt senaste släpp, om det hette v1.0.1:

$ git shortlog --no-merges master --not v1.0.1
Chris Wanstrath (6):
      Add support for annotated tags to Grit::Tag
      Add packed-refs annotated tag support.
      Add Grit::Commit#to_patch
      Update version and History.txt
      Remove stray `puts`
      Make ls_tree ignore nils

Tom Preston-Werner (4):
      fix dates in history
      dynamic version method
      Version bump to 1.0.2
      Regenerated gemspec for version 1.0.2

Du får en enhetlig sammanfattning av samtliga incheckningar sedan v1.0.1, grupperade efter författare, som du kan skicka till e-postlistan.