refs for activities

[mikaelkaron]

continuing from open-learning/pr#4 where @dominictarr said:

hey, so I read most of this material.

I see you have had the content-addressability revelation!

Though if you want to have true public verifications then you'll need to sign the commits (the name on a git commit is just a text field so you can make a commit with anyone's name on it)

Did you just write it up as git to explain how it works? This would be much easier to use if you made another tool that just wrapped git. With commands like list lessons create lesson which would manage git refs under the hood.

Im a little worried about this: https://github.com/open-learning/git4ol/blob/master/activities.md#assets how you are defining the steps within the refs - as a tree of refs. I worry you are overusing refs here. And it seems very strange to use git and then create another version manager (with those version numbers) on top of it. The problem here is that refs are just mutable pointers, and so while you can verify the git trees, you can't verify the refs... Would it be possible to put the steps into a file, and then check that in? then you can version the lessons with git.

[mikaelkaron]

I've been thinking along the same lines.

git refs are simply not stable enough and it's sometimes a pain to use them for stepping. However git refs are needed to give git an anchor to hold on to.

What if we keep refs but only to hang on to the last commit. We replace the pseudo-list of steps with an end commit where the commit message contains meta information about the whole lesson. This meta information would be encoded in the yaml part of a front-matter in the commit message.

[mikaelkaron]

Let me expand. What I have in mind is a commit formatted along these lines:

Lesson title

steps:
  - 1158e62
  - edef49d
  - 4241e04
  - c20460b
...
---
Lesson introduction in markdown format

So using git log -1 --format="---%nid: %H%n%ntitle: %s%nnotes:%N%n%b" like here we could get:

---
id: commit-id
title: Lesson title
notes:
steps:
  - 1158e62
  - edef49d
  - 4241e04
  - c20460b
...
---
Lesson introduction in markdown format

The should be the last commit in the lesson and we can have a git ref pointing to it.

Thoughts?

[mikaelkaron]

Not sure you see these @dominictarr since I only mentioned you in the description. Ping?

[dominictarr]

Hmm, so I feel like you are doing two things here - there is this idea about open learning platform - and then there is this mad science project about a replicated database. On the one hand you are avoiding reinventing the wheel by using git, but on the other hand you using old wheels on a new type of road, by using git as a generalized database...

I know a number of other people who are experimenting with content-addressable replicated data structures... there is ipfs, dat, @substack's forkdb, and my own project secure-scuttlebutt.

How far can you push git till it becomes easier to create a new thing?

[mikaelkaron]

Using git as a db is indeed one thing (and perhaps the part that makes least sense at first glance). What I find more attractive is:

• The workflow around forking (when there's only one student)
• Cherry-picking and such (when there's more than one student)
• Pull requests (for reviews)
• Integrations via githooks
• Using existing infrastructure (like github)
• Using existing tools (like gerrit)

And I also want the whole thing to sort of stop at the git4ol level really. One of the nice things about git4ol is that you can actually create content using just the git CLI if you want to, it's not new software at all, just conventions for existing software.

I agree that if we were looking at creating a better db for content git may not be the best, but I believe it's the easiest to start with and it certainly gives us enough headroom to grow in the future (like when we start thinking offline and alternate transports like smtp).

[dominictarr]

Those are certainly good arguments for using git, but do they hold up when you start using git in a weird way? I'm just not yet convinced that those tools will handle the way you are talking about using refs.

[mikaelkaron]

I have a test repo (this one actually) that uses refs for steps. The only extra work you have to do is to make sure to fetch those extra refs when you need them.

• Exactly what part do you think would not be working well with refs?
• If we don't use refs but a manifest commit, do you see any further problems?

[dominictarr]

ah well just if each step is a ref then the steps cannot be versioned as a collection.

[dominictarr]

what is a manifest commit?

[mikaelkaron]

A manifest commit would be something like what I described in this comment.

This would remove all the step/* and assignment/* refs. (The only ref we have to keep is the one ref to the manifest commit really)