Re: [RFC] git email submissions

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 16, 2005, 16:59 UTC
Message-ID: <Pine.LNX.4.64.0511160847250.13959@g5.osdl.org>
In-Reply-To: <437B4472.1080401@pobox.com>

On Wed, 16 Nov 2005, Jeff Garzik wrote:

> 
> For people without _any_ hosting, it would be nice to give them a method to
> submit some git changes via email.

Well, as long as you don't expect me to take those things..

BK had it with "bk send"/"bk receive", I used it a couple of times and refuse to do it again.

> - what form would the emails take?  MIME-attach a .pack file, plus a
> GPG-signed sha1sum in a separate attachment?

Yes, that sounds sane. You also need to specify the head(s) of the pack-file (maybe that's what you meant by the GPG-signed sha1sum).

Show 7 quoted lines

> - what's the easiest user interface for selecting the changes?  for my usage,
> it would be
> 
> 	GIT_GPG_AUTHOR=jgarzik... \
> 	GIT_DEF_HEADERS=./email.headers \
> 	git-mkmail --sign master..upstream > email.rfc822
> 	Enter GPG passphrase:

Sounds sane.

> - what user interface does a kernel maintainer use, to merge changes submitted
> using this method?

As long as it's not me, I'd suggest doing something like

	git getmail <path-to-git-repo> < raw-email

Why? Because a lot of email clients know how to pipe the email to a program, so you might use this from within the email client by just doing

	| git getmail myrepo

and please also have an option to make it do the equivalent of a "fetch" rather than a "pull" (ie to "get" it as a separate branch without the merge):

	| git getmail -b garzik myrepo

or something.

More importantly, the "git-getmail" (or whatever) scipt must absolutely be anal and verify that the pack is "complete". Since you don't have the git protocol to do the interactive "find the common parent" thing, it's easy for the other end to specify a commit you don't actually have, and make a pack that is perfectly valid, but which wouldn't have full connectivity to what the person that pulls is trying to get.

The minimal thing to do is to run a "git-fsck-cache" after the fetch and before the merge (if any). If the destination repo is regularly packed, it should even be fast (for example, since I repack my repo pretty regularly, a non-full fsck usually takes just a fraction of a second for me).

			Linus