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:
#!/bin/sh 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..
nice to haves:
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.)
suckless.org are already using this idea for updating their web pages.
+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.
suckless.org already uses a similar thing.