I'm having fun thinking about git semantics in terms of a conversation. "I didn't like how that conversation went, oh just make a new branch or rebase master"
I forgot about the security feature by GitHub: oauth_authorization.destroy – Personal access token (API) deleted automatically (found in a public repository)
Sure this is a joke, but it's not crazy to think about a distributed commit log as the basis for distributed messaging. That's why I'm starting GitQ, a ZeroMQ-like distributed messaging framework that offers full auditability, customizable conflict resolution, and lazy reconciliation. Use it for your next microservices architecture!
I'm already using git commit logs as a micro-blog! ...internal to myself.
I had all this tooling already to e.g. scrape all the git repositories in my projects directory, and aggregate them into an activity feed for reviewing my own productivity. A dedicated repository to git commit --allow-empty -m "..." in, for non-code work, seemed like a natural and logical enough step.
I've been toying with the idea of a git-backed MIME email, where each thread is a repo, each message is a commit, and send/receive semantics map to push/pull operations.
I don't work on it because I don't want to reinvent email -- a trap many have tried -- but I do want explore ways of doing content-addressed distributed messaging, and a DCVS gives you those for free.
that wouldn't be reinventing email. it'd be reinventing an email client, which is a great idea. HOWEVER a repo per thread seems ... not good. I'd go with a branch per thread. Maybe encode the subject in a way that git is happy with as a branch name but can be decoded to the original text or looked up from.
It's a bit about the protocol, a bit about the client, I think.
In worldspace, every message's direct descendants form a DAG, i.e. classic threading, so messages only know about their ancestors or successors.
The "inbox" contains many independent, unrelated threads. From a client's perspective, I can see wanting to treat the inbox as a repo containing many files, each file being a thread.
From a protocol perspective, the total contents and state of the parties' inboxes is not relevant (nor particularly wise to share); but you would want to push your changeset to a thread (i.e. a new message) to your recipient. A git changeset can affect many files, which is not consistent with the semantics I'd want to convey.
Sometimes I'll reply to two related posts in one email. Might be that gits ability to merge threads would be a bonus vs the usual idea of representing threads as trees.
public-inbox is a project to use git as a mailstore, so mailing list archives can be synced with a git pull. Not quite what you're describing, and they don't exactly have a detailed website, but: https://public-inbox.org/
34 comments
[ 4.2 ms ] story [ 79.6 ms ] threadAlso I think you need to slap a `npm install` in there--- I know you have node_modules in the repo but I think they don't really like being cloned.
Also, what repo is this writing to?
The repo is here:
https://github.com/git-chat-client/git-chat-messages
Also, I don't have OSX, so I'm not sure how to test that. Probably something with your git configuration or maybe my naive parsing of the logs?
Consider using a OAuth token.
I had all this tooling already to e.g. scrape all the git repositories in my projects directory, and aggregate them into an activity feed for reviewing my own productivity. A dedicated repository to git commit --allow-empty -m "..." in, for non-code work, seemed like a natural and logical enough step.
[1] https://shebang.ws/fugitive-readme.html
I don't work on it because I don't want to reinvent email -- a trap many have tried -- but I do want explore ways of doing content-addressed distributed messaging, and a DCVS gives you those for free.
In worldspace, every message's direct descendants form a DAG, i.e. classic threading, so messages only know about their ancestors or successors.
The "inbox" contains many independent, unrelated threads. From a client's perspective, I can see wanting to treat the inbox as a repo containing many files, each file being a thread.
From a protocol perspective, the total contents and state of the parties' inboxes is not relevant (nor particularly wise to share); but you would want to push your changeset to a thread (i.e. a new message) to your recipient. A git changeset can affect many files, which is not consistent with the semantics I'd want to convey.
Exactly what I need: the opportunity to merge when trying to read my email.