[RFC] git email submissions

[RFC] git email submissions

[Jeff Garzik]

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

It seems like most of the necessary stuff is already present in git to 
bundle up a set of changes.  The open questions in my mind are

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

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

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

- is this all pointless, since the submittor could just email patches? 
[IMO no, git trees are better merges than emailed patches]

Overall, I was thinking it would be nice to have some way to safely 
transmit a small part of a git tree, including all history information, 
since its easier to merge git trees than patches.

And for someone without the resources to obtain hosting, email may be 
the only way to publish a git sub-tree.

	Jeff

Re: [RFC] git email submissions

[Petr Baudis]

Dear diary, on Wed, Nov 16, 2005 at 03:38:42PM CET, I got a letter
where Jeff Garzik <jgarzik@pobox.com> said that...
> For people without _any_ hosting, it would be nice to give them a method 
> to submit some git changes via email.

What kind of people have no hosting whatsoever? There is plenty of free
web hosting sites, and that should be enough...?

> - is this all pointless, since the submittor could just email patches? 
> [IMO no, git trees are better merges than emailed patches]

Couldn't you just look at the applies-to string of the first patch in
the series, branch up from that commit, and at the end of the series do
the merge?

No special tool required, just a bit smarter applier.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [RFC] git email submissions

[Linus Torvalds]

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

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

Re: [RFC] git email submissions

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> 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.
> 

Personally I think it would be nice if you could do an augmented 
patchset so that the end result is the same (with the same SHA1 IDs) as 
if one had merged a pull, while still being a human-readable patchset. 
The advantage with that is that once merged it'll do the right thing on 
the author's end.  I think that's pretty much my answer to Jeff's 
question :)

	-hpa

Re: [RFC] git email submissions

[Jeff Garzik]

H. Peter Anvin wrote:
> Linus Torvalds wrote:
> 
>>
>> 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.
>>
> 
> Personally I think it would be nice if you could do an augmented 
> patchset so that the end result is the same (with the same SHA1 IDs) as 
> if one had merged a pull, while still being a human-readable patchset. 
> The advantage with that is that once merged it'll do the right thing on 
> the author's end.  I think that's pretty much my answer to Jeff's 
> question :)

Agreed.

Though as a disclaimer to Linus and others, I don't plan to use this in 
my own submissions to Linus.  Just thinking it would be a nice thing to 
have, because there are definitely users out there who don't (for 
whatever reason) have git-capable hosting.

I would presume an email body would look like

overall description of changes
git log master..HEAD | git shortlog
git diff master..HEAD | diffstat -p1
git diff master..HEAD
<pack file MIME attachment>

Smarter programs would send the overall description and pack file as 
"[patch 0/N]", and then post the for-review patches in separate emails 
as "[patch M/N]".

	Jeff

Re: [RFC] git email submissions

[Matthias Urlichs]

Hi, Jeff Garzik wrote:

> Smarter programs would send the overall description and pack file as 
> "[patch 0/N]", and then post the for-review patches in separate emails 
> as "[patch M/N]".

So you want to send the stuff twice? Ouch.

Seriously: We can mail patches, and we can re-base our changes.

Anything that's not covered by this is inherently complicated, such that
specifying the starting point(s) of a git-send-pack-mail invocation needs
to be handled by a program, else we *will* get *lots* of pilot errors.

Surprise: We already have a solution: host your archive someplace
and let git push+fetch handle everything.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Alan Turing thought about criteria to settle the question of whether
machines can think, a question of which we now know that it is about
as relevant as the question of whether submarines can swim.
		-- Dijkstra

Re: [RFC] git email submissions

[Junio C Hamano]

Jeff Garzik <jgarzik@pobox.com> writes:

> I would presume an email body would look like
>
> overall description of changes
> git log master..HEAD | git shortlog
> git diff master..HEAD | diffstat -p1
> git diff master..HEAD
> <pack file MIME attachment>

As Smurf commented, the delta data is sent twice if you sent a
pack of "^his mine" -- once as a textual diff and then the delta
data in the pack.  You can slightly do better than that.
Because you are sending the diff, the pack you send does not
have to include the post-image of patch application, and I
suspect your pack would not have to contain anything other than
commit objects.

Re: [RFC] git email submissions

[Martin Langhoff]

On 11/17/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> For people without _any_ hosting, it would be nice to give them a method
> to submit some git changes via email.

I'm sure SF.net will host GIT projects sooner or later. I'm planning
on offering support on Eduforge.org as soon as I have some free time.

cheers,


martin

Re: [RFC] git email submissions

[H. Peter Anvin]

Martin Langhoff wrote:
> On 11/17/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>For people without _any_ hosting, it would be nice to give them a method
>>to submit some git changes via email.
> 
> 
> I'm sure SF.net will host GIT projects sooner or later. I'm planning
> on offering support on Eduforge.org as soon as I have some free time.

What would be *totally awesome* is if SF.net would also automatically 
use "git cvsimport" to track the CVS-based projects thereon...

	-hpa