GitHub import/export support

[codemac]

Currently, diffscuss has an experimental import of github issues into a diffscuss mailbox.

What would be truly awesome is the following:

• Multiple backends: native git, gerrit, github, bitbucket/stash.
• Multiple frontend: emacs, vim, ???
• Multi-project mailbox: diffscuss mailbox

The problem is that the mailbox code right now assumes it's part of your git repository, which makes diffscuss an all or nothing choice.

Things that probably need to change to truly support an "offline review system":

• diffscuss mailbox support a separate, multi-project, mailbox (think: ~/.config/mailbox) that is not tied into an individual git repo. I would implement it as another, separate, local-only git repo.
• a configurable mailbox sync activity, which each backend would need code to support. The current sync is essentially "native git" and we could leave that as a null-sync, and then use git magic to manage it.

[tomheon]

Hi @codemac,

I think tweaking the architecture is, in some sense, the easy part, whereas the hard part is tackling the actual sync problems, so I'd strongly propose focusing first on github 2 way sync and then reworking for different backends.

Some of the issues I've hit already, for example, when experimenting with GH 2 way sync:

• the view you see on a pull request is not just comments on the pull request, but from many sources, including comments on commits (you can see some of this in all the things that get requested in the github export). We'd have to figure out how to write replies back to the correct places. This is obnoxious but I don't think impossible.
• identity resolution between the local user's address / name and what github expects--again, probably not impossible, but a pain, especially if you want to handle corner cases like "omg a comment that's not from me actually got in the diffscuss file and now I'm going to post it as ... me? or what?"
• dealing with threading and so on if comments are added / edited / deleted on GH while you're editing in diffscuss--I think, again, this is manageable, but there's a lot of testing to do to see how that's actually handled
• and so on

I'd be delighted to work on this--or share some work on this, but I think the mailbox part is the easier problem, and should probably come 2nd, after we understand the actual difficulties in 2 way sync with GH.

Does this make sense?

[codemac]

• Edmund Jorgensen [email protected] [2014-12-12 13:40]:

  Does this make sense?

Yes! Thanks for writing all that up! I just wanted to communicate if I go off the deep-end and implement some of this. Thank you for being an active maintainer of this project.

My thoughts were that essentially the new mailbox itself would be inside a git repo, and we'd solve different problems with different merge resolution strategies of git branches.

• Re: Github view resoultion: This will be about hacking up the git sync to put things where you expect. Definitely obnoxious work, but work that just needs to be done.
• Re: Github vs. local Identity resolution: ssh config should be sufficient. They have an API for fetching people's public ssh keys, and this could be used to match edits. Anything about conflicts I'd like to handle as part of git. Anything that comes from github.com goes into the github branch. Anything that comes from local-me goes on the local branch. Things are merged into master as they are successfully resolved. Edits to anything done by a user not in ssh config would get rejected on diffscuss push or whatever.
• Re: The deletion case is the hardest, but all of those cases are the same ones that github's own email interface has to deal with. I could probably run a few tests and figure out what they do.

I really do think these are all easily solved after adding a detached diffscuss git repo that's mailbox only, as all of these problems are currently solved by git as well in the 'embedded mailbox' current arch. It's a good model, and it's why things like git-annex depend on git similarly.

If I make any decent progress, I'll let you guys know. I really love this tool, and all of my workflow is in emacs. I'd love to use a different

// mickey