Ticket #586 (new enhancement)
git backend for infinoted
| Reported by: | chrysn | Owned by: | armin |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | infinoted | Version: | |
| Severity: | normal | Keywords: | |
| Cc: | Launchpad Bug: |
Description
when collaboratively working on files that are kept in a git repository, it'd be useful to have infinoted integrate bidirectionally with git. the workflow i have in mind is as follows:
- user goes to git repository, invokes infinoted --git
- the server starts up and loads all the files at HEAD
- commits coming from the same email address should end up in the same infinote user and be assigned random colors unless the user is known. for "knowing" users, there should be an infinote config file created in the git config dir that saves each git commiter's color and provides merging for user names and committer names (all email addresses mentioned in "aliases" below are merged to the "user" name jdoe)
- i suggest the server caches the files in .InfText?, as loading them means the server has to walk through a file's history to recreate the assignment of chunks to users, which is time consuming (similar to a git blame). those cached files should contain a metatag describing which commit they come from, so any changes coming from outside the infinoted server can be applied on top of that when it starts up.
- the server offers the documents for editing. users can connect and work as usual
- at a given point in time (this is particularly wobbly atm; let's for the moment say we commit at shutdown of the server), all the changes that happened since loading are converted into git commits. this is a tricky part and likely to require some heuristics, depending on how much the server remembers. the commits should be based on the commit the server was started on (or the last it committed), and each commit should only contain a single user's edits (using the "author" option in the config example below).
- if the state of the directory the server is run at is dirty and it can't commit without possibly destroying data, it should commit its final state to a branch named infinoted-dirty, and refuse to start until that branch is merged.
example config file .git/infinoted.conf:
[user jdoe] hue = 0.18556 author = John Doe <john@example.com> aliases = j@example.com john@web
some possibilities for further enhancements would be
- committing as a reaction to external events, eg chat lines like /infigit commit -m "we now agree on fnord". i'm not sure if it's a good idea to use git's syntax here, as we'd have to have some kind of filtering in place anyway because no arbitrary commands should be executed based on chat lines
- integration with ikiwiki (ikiwiki admins might already have noticed that by "john@web"). not sure how deeply that could be integrated, options range from "if you've got a clone of the ikiwiki, you can obviously use infinigit on it" to "put jinfinote into ikiwiki and you get a wiki that can be edited simultaneously while still having a versioning backend"
- reacting to other git actions like "git pull" or external edits
an initial proof of concept could externally convert git a git repo to a bunch of .InfiText? files and provide at least one-way sync and might even work for committing too (but with worse overall integraton).
Change History
Note: See
TracTickets for help on using
tickets.
