git email submissions

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

Dear diary, on Wed, Nov 16, 2005 at 03:38:42PM CET, I got a letter where Jeff Garzik <[email protected]> said that...

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

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.

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

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

-hpa

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.

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

Sounds sane.

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

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

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

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.

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   |  [email protected]
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