Les historikken: log, show og objektene bak

Den interaktive leksjonen trenger JavaScript. Teksten under er hele leksjonen.

Etter leksjonen kan du

• bruke git log med --oneline, --stat og -- <fil> for å finne commiten som endret en bestemt fil anvende
• peke på eldre commits relativt til HEAD med HEAD~1 og HEAD~2, og vise en gammel filversjon med git show anvende
• forklare hvorfor en commit-ID endres når innhold, forelder eller melding endres forstå
• følge en commit til tree og blobs med git cat-file -p og git ls-tree, og forklare hvorfor uendrede filer deler blob anvende

Forstå: Hva historikken består av

git log viser historikken med den nyeste commiten øverst: ID, forfatter, tidspunkt og melding. Valg styrer detaljnivået. --oneline gir én linje per commit, --stat viser hvilke filer som ble endret, og -p viser selve endringene.

ID-en er en hash: et fingeravtrykk på førti tegn som regnes ut fra alt i commiten. Det gjelder snapshotet, forelderen, forfatteren, tidspunktet og meldingen. Endrer du noe av det, får du en annen ID. Som regel holder de første sju tegnene.

Du trenger sjelden å skrive ID-er. HEAD~1 betyr ett steg tilbake fra der du står, altså forelderen. HEAD~2 er to steg tilbake.

Hva er inni en commit? Commit D peker på et tree, innholdsfortegnelsen til snapshotet. Treet lister to filnavn, og hvert navn peker på en blob, altså innholdet i én fil. D lagrer også ID-en til forelderen sin, C. Det er pilen i grafen.

Hver commit lagrer ID-en til forelderen sin, så ID-ene henger sammen i en kjede. Endrer du noe i B, blir det en ny commit med ny ID. C peker fortsatt på den gamle B, så for å bygge videre må C og D også lages på nytt, med nye ID-er. Ingen kan endre historikken i det stille.

Se demo: Fra log til blob

Dette prosjektet har fire commits. --graph tegner linjen mellom dem. Her er den rett. Når vi får brancher senere, deler den seg.

$ git log --oneline --graph

Med --stat ser vi hvilke filer hver commit endret. Med -- og et filnavn viser git log bare commits som endret den filen.

$ git log --oneline --stat

git show HEAD~1 viser forelderen til den nyeste commiten. Vi får ID, forfatter, tid og melding, og under det diffen mot dens egen forelder. Git regner ut den diffen nå. Den er ikke lagret.

$ git show HEAD~1

Nå ser vi selve commit-objektet. Det peker på ett tree og én forelder. Se på parent-linjen: det er ID-en til commiten vi nettopp viste. Den linjen er pilen i grafen.

$ git cat-file -p HEAD

Treet er innholdsfortegnelsen. Hver linje har et filnavn og ID-en til en blob. Merk deg starten på ID-en til README.md.

$ git ls-tree HEAD

Den nyeste commiten endret bare INSTALL.md. Hva tror du skjer med README.md i snapshotet før?

$ git ls-tree HEAD~1

HEAD:README.md betyr blobben til README.md i HEAD. Blobben er bare innholdet. Den har verken navn eller dato. Navnet står i treet. I objektvisningen ser du at begge treene peker på denne samme blobben.

$ git cat-file -p HEAD:README.md

Oppgaver

1. Vis historikken kompakt, med grafen.
2. Vis hvilke filer hver commit endret.
3. Vis commiten rett før den nyeste, med endringene.
4. Skriv ut det rå commit-objektet til HEAD.
5. List filene i det nyeste snapshotet, med blob-ID-ene.
6. List filene i snapshotet før det nyeste, og sammenlign ID-ene.
7. Skriv ut innholdet i README.md slik det er lagret i den nyeste commiten.

Øv: Overfør: grav i en handleliste

Et nytt repository med fem commits. Først leser du historikken og finner svar. Til slutt lager du én commit for å undersøke hva en commit-ID består av.

Oppgaver

1. Finn commiten som sist endret README.md, og skriv ID-en dens i en ny fil answer.txt. Kort ID holder.
2. Lagre list.txt slik den så ut to commits før den nyeste, i en ny fil old-list.txt. Selve list.txt skal være uendret.
3. Lag en ny commit som har nøyaktig de samme filene som forelderen sin. Bekreft så at de to commitene har ulike ID-er, men samme tree.

Sjekk deg selv: Hent det fram igjen

Historikken er A, B, C, D, E, der E er nyest og HEAD peker på E. Hvilken commit er HEAD~2?

• D
• C
• B

To commits har nøyaktig de samme filene. Har de samme ID?

• Ja, ID-en regnes bare ut fra filene
• Ikke nødvendigvis: forelder, forfatter, tid og melding inngår også
• Nei, ID-er er tilfeldige tall

Du gir notes.txt det nye navnet ideas.txt uten å endre innholdet, og committer. Hva lagrer den nye commiten for ideas.txt?

• En ny blob med det nye navnet
• En linje i det nye treet som peker på den gamle blobben
• Ingenting, fordi bare endringer lagres

Repetisjon fra leksjonen om gode commits: git log --oneline viser én linje per commit. Hvilken del av commitmeldingen er det?

• Emnelinjen, altså første linje i meldingen
• Brødteksten, fordi det er der forklaringen står
• Et sammendrag Git lager av diffen

Vanlige misforståelser

• «En commit-ID er et tilfeldig tall eller et løpenummer.» Den er en hash av hele commiten, også forelder, forfatter, tid og melding.
• «HEAD~2 er commit nummer to.» Tilde teller bakover fra HEAD, ikke fra starten.
• «Fullstendige snapshots må ta mye plass.» En uendret fil peker på den samme blobben som før.

$ printf 'Welcome\nA tiny demo project.\n' | git hash-object --stdin
5f6e829bc5a7fcde1c549bf31b1292e3762a75ec

$ git ls-tree HEAD
100644 blob a2f179b6e361876a40e3debec4ab5d59af100618    INSTALL.md
100644 blob 5f6e829bc5a7fcde1c549bf31b1292e3762a75ec    README.md

$ git cat-file -p HEAD
tree b1a2df414fdbe20c422e0f593dd0952bfb400b08
parent 2a59dab4dcabe5f8d025d1ab94d1015d680fc576
author Student <student@example.invalid> 1791875457 +0200
committer Student <student@example.invalid> 1791875457 +0200
Use npm ci in install guide

$ git commit --allow-empty -m "Mark review point"
$ git rev-parse HEAD HEAD~1 'HEAD^{tree}' 'HEAD~1^{tree}'
f86942208ecf3829d56f9b045b009cbd2a4f2c73
b3706e8326424b35f7a5c8e7c8870730b728d667
b1a2df414fdbe20c422e0f593dd0952bfb400b08
b1a2df414fdbe20c422e0f593dd0952bfb400b08

$ git log --oneline -- INSTALL.md
b3706e8 Use npm ci in install guide
3cd1670 Add install guide
$ git log --oneline -S "npm ci"
b3706e8 Use npm ci in install guide

$ git log --oneline HEAD~2..HEAD
f869422 Mark review point
b3706e8 Use npm ci in install guide

$ git show HEAD~9
fatal: ambiguous argument 'HEAD~9': unknown revision or path not in the working tree.
$ git show HEAD:nope.md
fatal: path 'nope.md' does not exist in 'HEAD'