Git push over XMPP | Hacker News Reader

Git push over XMPP

joeyh.name

78 pointsbokchoi17 comments

Interesting. I think there's a demand for a generic, protocol-agnostic git push framework where you can write plugins for both sending and automated receiving.

All git patches boil can be boiled down to ASCII patches. There's no reason you can't write a framework to send/receive ASCII-formatted git patches/pulls/pushes via email, xmpp, twitter, etc.

How does git handle binary/highorder byte data for patching?

Git sends data between repositories using a pack format that transfers the raw blob/tres/commit/tag objects, not patches.

It uses a custom delta compression algorithm, based on libXDiff. You can see that output using "git diff --binary". I believe these are the relevant parts of the source code:

https://git.kernel.org/?p=git/git.git;a=blob;f=diff-delta.c;...

https://git.kernel.org/?p=git/git.git;a=blob;f=diffcore-delt...

Darcs's send and apply work on this principle, of course, though I haven't seen it applied to XMPP specifically. As I recall, the manual even has an example of how to add an easy hook in Mutt to apply a patch from email. git diff and git apply are available for single patches, of course, and git format-patch and git am are optimized for the mail case so that multiple commits can be sent at once, though darcs apply has integrated PGP signature checking and at a glance I don't see anything similar in the git versions. git-send-pack and git-receive-pack also have an underlying role not strongly coupled to the overlay transport, but seem to be designed for bidirectional communication so that the repositories can negotiate about which objects they already have.

Git 1.7.9 added the ability to sign commits. Previously you could only sign tags:

  * "git commit" learned "-S" to GPG-sign the commit; this can be shown
   with the "--show-signature" option to "git log".

man git:

  All objects are named by the SHA1 hash of their contents, normally 
  written as a string of 40 hex digits. Such names are globally unique. 
  The entire history leading up to a commit can be vouched for by signing
  just that commit."

There's signed commits, yes. Is there also "apply these but only if they have a valid signature from one of these people"? That's what I didn't see.

What would be really nifty would be the ability to add multiple signatures to commits.

Take a commit with signature[s], add a new signature (create a new commit that contains the previous signature[s] (which should still be valid if you don't change anything else) + your own).

I looked into this very briefly and think it should be possible, but didn't go any further than that.

This would I think be neat for creating things like code review systems that require a certain number of signatures from a larger set of potential signers before automatic deployment.

If you're interested in building this kind of thing, JGit might be a good starting point, as it offers the right amount of flexibility [1] to be able to pull this off and stay sane in the process [2].

[1]: A good example would be http://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit... (Git over Amazon S3)

[2]: If programming Java allows you to do this, of course. I'm not too deep into the JVM ecosystem, so I don't know if you could just use a language that compiles to JVM bytecode.

I've been wondering about the possibility of doing this ever since I saw that Joey has been working on XMPP stuff for git-annex. Would be very nice to see this become a thing of it's own.

I really like this idea, and kudos to the author for coming up with a pragmatic (if possibly insane) way to get things done... but when I read stuff like this:

  > Imagine if you could send git pushes to any of your friends on
  > Google Talk or other Jabber (XMPP) servers. Even though you're in
  > different places and your computers probably cannot talk to
  > one-another directly, you can share a git repository, without
  > relying on a git hosting provider such as GitHub.

I really just want to weep. Hopefully some of this will go away with ip6 (no more silly NATing for nothing). Broken networks with asymmetric bandwidth hawked by dying conglomerates protecting their ancient signalling technology (and now antiquated media distribution channels) will haunt us for decades.

[edit: quote formatting]

Especially since in practice for most people they'll just be replacing a third party git hub with a third party xmpp server. Which of course is of benefit to those that don't know they might want to have a github/shell account with their own git on it -- but more or less swaps out one problem for another (almost) equivalent problem.

I agree of course.. But it's even worse than that. Seems like half the time ipv6 comes up on NANOG, they're talking about the abdomination that is NAT66. (Rest of the time they're talking about NAT46 of course.)

I have little confidence in the Internet's end-to-end routing getting fixed unless and until the Internet backbone itself changes shape to something less conducive to monopoly.

hm as someone who always has a few servers up in the cloud i found the idea exotic at first. especially since you dont need github, any ssh connection between two computers will do. but thats not always easy and the more i think about it, git over xmpp sounds like a cool idea. but still, in the end one can just email or dropbox the whole zipped repo. and git patches and whatnot.

I think, using git for what it traditionally is used for, there probably isn't much demand for XMPP. Joey's thing seems to be expanding the horizons of what we can use git for though. Building cooler toys out of git, not just with it.

This sounds really neat. What's it used for, though?

Syncing between Git-Annex Assistant instances: http://www.kickstarter.com/projects/joeyh/git-annex-assistan...

Reply on news.ycombinator.com