Re: email as a bona fide git transport

From: Jonathan Nieder
Date: Wed Oct 16 2019 - 16:57:42 EST


A few small points.

Vegard Nossum wrote:

> * git am (or an alternative command) needs to recreate the commit
> perfectly when applied, including applying it to the correct parent

Interesting. "git format-patch" has a --base option to do some of
what you're looking for, for the sake of snowpatch
<>. Though it's not exactly the
same thing you mean.

We also discussed sending merge commits by mail recently in the
virtual git committer summit[1].

Of course, the devil is in the details. It's straightforward to use
"git bundle" to use mail as a Git transport today, but presumably you
also want the ability to perform reviews along the way and that's not
so easy with a binary format. Do you have more details on what you'd
want the format to look like, particularly for merge commits?

> there
> is no need for "changeset IDs" or whatever, since you can just use the
> git SHA1 which is unique, unambiguous, and stable.

In [2] the hope was for some identifier that is preserved by "git
rebase" and "git commit --amend" (so that you can track the evolution
of a change as the author improves it in response to reviews). Is
that the conversation you're alluding to?

> Disadvantages:
> - requires patching git

That's not a disadvantage. It means get to work with the Git project,
which is a welcoming bunch of people, working on userspace (seeing how
the other half lives), and improving the lives of everyone using Git.

> Date: Sat, 5 Oct 2019 16:15:59 +0200
> Subject: [PATCH 1/3] format-patch: add --complete
> Include the raw commit data between the changelog and the diffstat.

Oh! I had missed this on first reading because it was in an

I have mixed feelings. Can you say a bit more about the advantages
and disadvantages relative to sending a git bundle? What happens if a
mail client or a box along the way mangles whitespace in the commit

Happy hacking,