Hacker News Reader

Comment by ComputerGuru | Hacker News Reader

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.

View on HN

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.

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...

Reply on news.ycombinator.com