Open mikaelkaron opened 9 years ago
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.
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?
Not sure you see these @dominictarr since I only mentioned you in the description. Ping?
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?
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:
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).
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.
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.
ah well just if each step is a ref then the steps cannot be versioned as a collection.
what is a manifest commit?
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)
continuing from open-learning/pr#4 where @dominictarr said: