git decentralized

— a presentation I’ve given recently as costa works…

…was a mediocre success; no, I mean, the reception was good and some points did appear to have been made, but few have really appeared to follow my mainline train of thought: technology (which is provided) aside, turning collaborative workflows back into series of direct human interactions — as opposed to robo-bureaucratic processes (with infantile-designed UIs, surely) — can benefit any R&D enterprise — where authors exchange their formal-language materials (e.g. code) and are… somewhat personally removed from RL already, eh; professional doesn’t have to be bureaucratic, however corporates like M$ like you to believe.
The social situation — and the weather — at the locality of the presentation was very hot, and it took me a while to arrive at the (quick-witted genius!) conclusion of regular people — not just us, geeks — already preferring robots over humans to interact with — especially at their dreaded jobs… which I called:

Le Changement d’Ambiance

But anyway, for those still-warm humans in this global chillshow, here’s the summary (TL;DR) of “git decentralized”.

via hub: Commit > Push > pulL || Commit > fetcH > mergE :directly

• invest in human communication
• use minimal protocol for work
• stay in your source-code editor
• ask costa about “self server”

OK, and here’s some more materials from the presentation and its aftermath — with bits of practical knowledge within. For instance, here’s how I’ve illustrated the difference in git uses — centralised vs de-:

Or the main reveal slide, surprise:

git is *ackchyually* a decentralised protocol

With git, everyone within a project has its repo already.
Now, what if your peers’ repos were accessible as git remotes…

And git operation — with remotes, once they’re accessible — is reduced to:

unlike the original patch-by-email decentralized Linux’s workflow, git remotes are very simple*

• init, clone (one-off, can somewhat be automated)
• remote add, remove, fetch (can be fully automated)
• add, stash, diff, etc (local conveniences, in any IDE)
• commit, merge (the work in workflow, in any IDE)
• branch checkout, delete, rename (the flow in workflow, in any IDE)

*one way to git remote accessibility is a company-wide shared FS (with regular user home directories and permissions), so remotes point to something like:
[file://]/home/alice/a-project/.git — plus a commit hook script (with git update-server-info)

Bonus: but wait, no PR? (how to review code and to accept changes)

• find someone available to review changes on a branch
• ask them to review the branch
• they review your code — by editing your code
  e.g. adding # XXX comments
• do something else until they’re done — or pair with them for review
• git-diff in your editor and see their changes — including those comments
• change your code, remove excess (e.g. # XXX) comments
• if needed, repeat
• if not, either of you, merge to trunk
• ……………..aaaaaaand get back to work, there’s nothing to celebrate here!

And finally, a demo of a decent implementation with a self server platform, where project peers just stay in their favourite editors — and in meaningful direct communication with each other:

p.s. All credit for some success of the original presentation (not being a total failure) goes to https://www.meetup.com/github-user-group and its admins.