4 ms·
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 bran
by masukomi 10y ago
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.
- niftich 10y agoIt'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.
- Gibbon1 10y agoSometimes 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.
- pilooch 10y agoyou may want a branch per mailbox so that you can merge them, fork etc