This is an idea that Keith Packard told me. It's a brilliant way to reduce GitHub's growing lockin, but I don't know how to implement it. And I almost forgot about it, until I had another annoying "how do I send you a patch with this amazing git technology?" experience and woke up with my memory refreshed.

The idea is to allow anyone to git push to any anonymous git:// repository. But the objects pushed are not stored in a public part of the repository (which could be abused). Instead the receiving repository emails them off to the repository owner, in a git-am-able format.

So this is like a github pull request except it can be made on any git repository, and you don't have to go look up the obfuscated contact email address and jump through git-format-patch hoops to make it. You just commit changes to your local repository, and git push to wherever you cloned from in the first place. If the push succeeds, you know your patch is on its way for review.

Keith may have also wanted to store the objects in the repository in some way that a simple git command run there could apply them without the git-am bother on the receiving end. I forget. I think git-am would be good enough -- and including the actual diffs in the email would actually make this far superior to github pull request emails, which are maximally annoying by not doing so.

Hmm, I said I didn't know how to implement this, but I do know one way. Make the git-daemon run an arbitrary script when receiving a push request. A daemon.pushscript config setting could enable this.

The script could be something like this:

set -e
tmprepo="$(mktemp -d)"
# this shared clone is *really* fast even for huge repositories, and uses
# only a few 100 kb of disk space!
git clone --shared --bare "$GIT_DIR" "$tmprepo"
git-receive-pack "$tmprepo"
# XXX add email sending code here.
rm -rf "$tmprepo"

Of course, this functionality could be built into the git-daemon too. I suspect a script hook and an example script in contrib/ might be an easier patch to get accepted into git though.

That may be as far as I take this idea, at least for now..

some additions
  • grep for a change-id in the commit message and use this (or a random id) as the identifier of the change request
  • use the change-id instead of $tmprepo
  • use the change-id to allow multiple, evolving versions of the same change request. Every new version of the same change-id gets a new branch in the repo

nice to haves:

  • only allow signed commits with a trusted gpg key
  • add the authors email to an add-hoc mailing list for this change request
  • allow others to subscribe to the discussion, well use the debian bugtracker and make each change request a bug ... :-)
  • come up with a standard data format for inline comments and provide a facility to comment the code and render the code comments inside a git web interface
Comment by thkoch
Push to the BTS?

Another possibility would be to invoke the bug tracker and create a new issue, so it isn't stuck in one person's mailbox or spewed to a list. Someone can claim it. (Or just give the sender an account on the Git server and assign the issue to him or her.

(This would make an excellent feature for a fully git-backed BTS/SCM thing too. To file a bug, commit on a databranch and push.)

Comment by dmarti []

+1 but please not the over-the-top suggestions from the others.

Just a gateway of a received push to “git am”able eMails (and, more importantly, ones where I can reply to the patch inline, i.e. where it doesn’t hide behind a MIME curtain) would be decent.

Comment by mirabilos