git: a transcriptional database

I had a thought yesterday while biking into town. Git is a transcriptional database -- it writes and writes and writes, and what we are left with is its transcript. I wouldn't call it a transactional database, since it has no rollback operator. It doesn't need one. Ref updates either succeed or fail. If they fail, well, write, write again:

The Moving Ref writes; and, having commit,
Moves on: cosmic Rays nor Zero-blit
Shall untrue its blobs, its trees Unbind,
Nor all your Pushes flip a Single bit.

It is perhaps not as beautiful as Fitzgerald's translation, but the bar was set quite high. To compensate, here is what is, to my knowledge, the first translation of Khayyam into Scheme:

(define (git-update-ref refname proc count)
  (let* ((ref (git-rev-parse refname))
         (commit (proc ref)))
    (cond
     ((zero? count) #f) ; failure
     ((false-if-git-error
         (git "update-ref" refname commit ref))
      commit)
     (else
      (git-update-ref (git-rev-parse refname) (1- count))))))

The rest of the text may be found in tekuti.

related articles

4 responses

  1. bartman says:

    No rollback? How about git checkout or git reset? Both of those roll back some subset of changes depending on arguments.

  2. wingo says:

    Neither checkout nor reset affect the database. "Checkout" affects the ephemeral "working tree", one instance of an area in which to stage changes. "Reset" changes the values of ref pointers. But as far as the object database goes, all writing is on clean sheets of paper: nothing is ever overwritten.

  3. ulrik says:

    I must be a real git nut, no even totally nutty since I was thinking about starting a comment with "Git speaks to us and tells us.."

    Anyway what I think that was about is the question why git's internals are so interesting and those of other scms not. It seems that git's internals are very well designed and indeed I believe Linus now he claims "Design your datastructures well and the rest will be natural".

    I like git a lot. What it tells us is that the end result is uncomplicated and getting there is just a number of small steps, each of them pretty simple. Then on top of that simplicity you can build magic like git-blame or git-repack.

  4. wingo says:

    Ulrik, even if you're a nut, you're in good company :)

Comments are closed.