Date: Mon, 06 Jan 2020 00:04:58 +0000
From: Katharina Fey <kookie@spacekookie.de>
To: mgattozzi@gmail.com
Subject: Thoughts about git email tools 
Message-ID: <6924A6AC-238F-4BCC-B8FA-2478DB628D72@spacekookie.de>
X-TUID: 2W6l53yvRAbF

Hey,

I will propably also publish this on my public-inbox [1], but didn't
want to just CC it because I didn't know if you were gonna be okay with
your email address being indexed there.  Let me know if that's something
you're okay with for future correspondance.

So here's my thoughts: I don't really like the idea of pull requests.
They require me to use a web UI in most cases, or just to have an
account on someone elses server.  It's easy for people or institutions
to create vendor lock-in, with them as well, because you have to be on a
specific platform to contribute to a project.  This is really how Github
got into the situation they're in now and I think we don't get to
decentralise again without fundamentally challenging the design
decisions that it made.

There's some efforts to use something like activitypub to host code and
make pull requests federate but I think that's still not the right
approach: it still locks you to a piece of software additionally to git,
because only some server implementations are going to support this.
Furthermore, you still need to register an account somewhere!  It's not
possible to just send some patches to someone as a one-off, without
having to host code somewhere yourself.

So, I do think that e-mail is a good candidate here. It's both a
universally supported exchange format for patches, as well as giving
people the opportunity to have truely threaded discussions about changes
that are being made.  It's not a _pretty_ standard but it is one that
everything supports and I think that there should be better tooling for
it.  I'll go through some of the pain points that I've found in the last
year or so doing colaboration via email on various projects:

1. Sending with both git-send-email and git-format-patch is confusing,
   and it's not clear to people how to use the two tools, and when.

2. Most people don't know or understand how to create proper replies
   because it requires getting the mail id from a mail client that might
   entirely hide the headers from you.

3. I think this workflow lacks communication, that email for git is only
   an exchange format, and that people aren't expected to write it by
   hand.  I've seen quite a few people getting frustrated with projects
   not being able to apply patches that they sent because they formatted
   patches with git-format-patch and then using thunderbird or similar
   to send the patches (that do weird text wrap things)

4. On the applying side of things there's even more annoyance, even for
   people who are very experienced with git.  If you're using a mail
   client like thunderbird, it's really not clear how to apply patches,
   especially if they come in a set, not just a one-off.  You'd have to
   save all the patches, then use git-am on the terminal to apply them.
   Now, if someone sends a 2nd revision, you need to go through that
   whole dance again.  I use notmuch in emacs as a mail client which
   allows me to do quite a lot of custom stuff with lisp, so I have a
   fuction that takes a patchset and applies it to a repo, which I can
   then just repeat for a 2nd iteration.  But I don't think that's a
   reasonable solution for everyone.

I think maybe looking at how to send patches and how to apply them
separately, but trying to create a more unified user interface might be
nice.

## On the sending side

- Allow a tool to hook into mail storage, either by parsing local mail
  (mbox, maildir, ...) or by using smtp to access mail directly from the
  server

- Select a base commit/branch, the same way you would for a PR.  This
  can just be HEAD~~3 on master, but make it easier to understand that
  that's what's happening.  I think a lot of people also don't know how
  the "~~" syntax works either.

- Make it easy to see where to send a patch and also who to CC directly,
  because maybe they're a module maintainer on a project?

- With access to previous mails we can also do things like figure out
  reply IDs for a second revision to a patchset.  This way people don't
  have to go digging through their email manually to find previous
  patches.

- Because email is also how someone would get comments on their code,
  all of this needs to remain being standard email stuff, but there's
  definitely some quality of life improvements to be made.

## On the applying side

- Again, have something that can interact with my mail store, wether
  that is somewhere in the cloud or on my computer if I download them.

- Show me available patches in a set, potentially in various revisions.
  If a complete set of a higher revision exists, that should propably be
  the default to pick, but that doesn't mean someone might not want to
  customise their selection.

- I think a TUI would work really well here where people can be shown a
  thread, and then letting them pick which versions of patches they
  want.  Maybe the last revision of a commit was the reply to an email
  that is 10 levels down because some yakshaving had to happen first.
  In eithre case, the applying of emails should be separate from the
  main mail program the user is already using.

- We could even do stuff like trying to apply every patch in a set and
  then showing a little "!" when something has conflicts, so someone can
  see that at a glance.

- Oh and automatically skip cover letters but honestly that's such a big
  one I might try to get the patch for that I wrote into the git
  upstream tree.


Right so...sorry for this massive wall of text.  I guess I've been
thinking about all of this for a while but never really wrote it down
before.  I'm curious what you think, if this was the direction you were
thinking about going into, etc.


Cheers, and have a lovely day,
Katharina


[1]: https://lists.sr.ht/~spacekookie/public-inbox

---
From: Michael Gattozzi <mgattozzi@gmail.com>
To: Katharina Fey <kookie@spacekookie.de>
Date: Sun, 5 Jan 2020 22:27:06 -0500
Subject: Re: Thoughts about git email tools
References: <6924A6AC-238F-4BCC-B8FA-2478DB628D72@spacekookie.de>
In-Reply-To: <6924A6AC-238F-4BCC-B8FA-2478DB628D72@spacekookie.de>
Message-ID: <CANjKBrspY4DrS9p2ig0CMhv8HbdiwNMdh5Rr86LbJ-hRNBkzoQ@mail.gmail.com>


Hey Katharina!

Feel free to CC me to it! I appreciate asking first, but I'm not that
private about my code or what I talk about with it.
The gripe I have with email is that we really shouldn't be sending patches
by it for a lot of the reasons you mentioned,
formatting being the biggest. git has all the capabilities to pull in
commits as if they were in your own copy as long as
there's a public copy to pull from. Just git fetch and you have it. The
failure mode is when someone doesn't have a public
copy people can pull from. In this case emailing a patch seems like a next
best step (and something I've had to do before).

I think email as a means of collaboration as in "Here I made this change
you can pull it from here" as a notification system
is better and like you've said federation fails in many cases and
centralization kind of defeats the point of git. Some projects
like git only accept patches by email.

I like a lot of what you have written down. I want people to be able to do
distributed review somehow and email isn't the worst
way, it's just difficult currently! Now I don't think this is exactly what
I had in mind, because as I alluded to earlier, the idea of
sending a patch in the email, when I can pull it from git which is designed
to handle this seems better, but having email be a
system of notification that's built into git is probably our best bet at a
good system.

Now granted it is late as I'm sending this and I'm not fully baked into any
particular idea. I like the idea of supporting multiple
different workflows in dev-suite, whether it's by patch or how I've done
things. Email in git is just too damn confusing and I
likely need to use it as a notification system anyways so even just being
able to pull in the patchset just to look at it sort of
like on GitHub would be a better experience than the email back and forth
that exists today.

I really liked what you laid out and would love to help come up with some
way we could make email and git better. I feel like
that there's a lot to learn here that I just plain don't know or understand
and working on this kind of tooling would be great.
GitHub came about because the mailing lists and patches sent on old
projects was tough. I think we can make that
experience, not only better, but as easy to use as GitHub. If that all
makes sense I feel like I was a bit rambly here in the
email. Needless to say: Email good, current interface with git awful and I
think we can make it better somehow.

Best,
Michael

On Sun, Jan 5, 2020 at 7:05 PM Katharina Fey <kookie@spacekookie.de> wrote:

> Hey,
>
> I will propably also publish this on my public-inbox [1], but didn't
> want to just CC it because I didn't know if you were gonna be okay with
> your email address being indexed there.  Let me know if that's something
> you're okay with for future correspondance.
>
> So here's my thoughts: I don't really like the idea of pull requests.
> They require me to use a web UI in most cases, or just to have an
> account on someone elses server.  It's easy for people or institutions
> to create vendor lock-in, with them as well, because you have to be on a
> specific platform to contribute to a project.  This is really how Github
> got into the situation they're in now and I think we don't get to
> decentralise again without fundamentally challenging the design
> decisions that it made.
>
> There's some efforts to use something like activitypub to host code and
> make pull requests federate but I think that's still not the right
> approach: it still locks you to a piece of software additionally to git,
> because only some server implementations are going to support this.
> Furthermore, you still need to register an account somewhere!  It's not
> possible to just send some patches to someone as a one-off, without
> having to host code somewhere yourself.
>
> So, I do think that e-mail is a good candidate here. It's both a
> universally supported exchange format for patches, as well as giving
> people the opportunity to have truely threaded discussions about changes
> that are being made.  It's not a _pretty_ standard but it is one that
> everything supports and I think that there should be better tooling for
> it.  I'll go through some of the pain points that I've found in the last
> year or so doing colaboration via email on various projects:
>
> 1. Sending with both git-send-email and git-format-patch is confusing,
>    and it's not clear to people how to use the two tools, and when.
>
> 2. Most people don't know or understand how to create proper replies
>    because it requires getting the mail id from a mail client that might
>    entirely hide the headers from you.
>
> 3. I think this workflow lacks communication, that email for git is only
>    an exchange format, and that people aren't expected to write it by
>    hand.  I've seen quite a few people getting frustrated with projects
>    not being able to apply patches that they sent because they formatted
>    patches with git-format-patch and then using thunderbird or similar
>    to send the patches (that do weird text wrap things)
>
> 4. On the applying side of things there's even more annoyance, even for
>    people who are very experienced with git.  If you're using a mail
>    client like thunderbird, it's really not clear how to apply patches,
>    especially if they come in a set, not just a one-off.  You'd have to
>    save all the patches, then use git-am on the terminal to apply them.
>    Now, if someone sends a 2nd revision, you need to go through that
>    whole dance again.  I use notmuch in emacs as a mail client which
>    allows me to do quite a lot of custom stuff with lisp, so I have a
>    fuction that takes a patchset and applies it to a repo, which I can
>    then just repeat for a 2nd iteration.  But I don't think that's a
>    reasonable solution for everyone.
>
> I think maybe looking at how to send patches and how to apply them
> separately, but trying to create a more unified user interface might be
> nice.
>
> ## On the sending side
>
> - Allow a tool to hook into mail storage, either by parsing local mail
>   (mbox, maildir, ...) or by using smtp to access mail directly from the
>   server
>
> - Select a base commit/branch, the same way you would for a PR.  This
>   can just be HEAD~~3 on master, but make it easier to understand that
>   that's what's happening.  I think a lot of people also don't know how
>   the "~~" syntax works either.
>
> - Make it easy to see where to send a patch and also who to CC directly,
>   because maybe they're a module maintainer on a project?
>
> - With access to previous mails we can also do things like figure out
>   reply IDs for a second revision to a patchset.  This way people don't
>   have to go digging through their email manually to find previous
>   patches.
>
> - Because email is also how someone would get comments on their code,
>   all of this needs to remain being standard email stuff, but there's
>   definitely some quality of life improvements to be made.
>
> ## On the applying side
>
> - Again, have something that can interact with my mail store, wether
>   that is somewhere in the cloud or on my computer if I download them.
>
> - Show me available patches in a set, potentially in various revisions.
>   If a complete set of a higher revision exists, that should propably be
>   the default to pick, but that doesn't mean someone might not want to
>   customise their selection.
>
> - I think a TUI would work really well here where people can be shown a
>   thread, and then letting them pick which versions of patches they
>   want.  Maybe the last revision of a commit was the reply to an email
>   that is 10 levels down because some yakshaving had to happen first.
>   In eithre case, the applying of emails should be separate from the
>   main mail program the user is already using.
>
> - We could even do stuff like trying to apply every patch in a set and
>   then showing a little "!" when something has conflicts, so someone can
>   see that at a glance.
>
> - Oh and automatically skip cover letters but honestly that's such a big
>   one I might try to get the patch for that I wrote into the git
>   upstream tree.
>
>
> Right so...sorry for this massive wall of text.  I guess I've been
> thinking about all of this for a while but never really wrote it down
> before.  I'm curious what you think, if this was the direction you were
> thinking about going into, etc.
>
>
> Cheers, and have a lovely day,
> Katharina
>
>
> [1]: https://lists.sr.ht/~spacekookie/public-inbox
>