Re: Merge projects?

[Kyle Meyer <kyle@kyleam.com>]

Xinglu Chen writes:

> Hi,
>
> I recently discovered piem and find it very interesting.

Glad to hear it, especially because it's not the easiest project to
discover :)

> I myself am working on a project called git-email[0], as the name
> suggests it tries to integrate git and email more closely with Emacs.

Thanks for the pointer.  It makes me happy to see work in this area.

> The two projects seem to have some overlap, since your project seems
> to be the more polished one, I wonder if I could maybe port some
> things to this project.  Any thoughts on this?

I'm responding before looking over git-email closely, but it seems the
two main features at this point are support for 1) applying the patch
from the current buffer and 2) sending patches.  The first does overlap
with some piem functionality [1], and I'd definitely welcome any
improvements, provided they don't interfere with or complicate
public-inbox/b4 functionality (more on that below).

The second feature (sending patches) isn't something I had really
imagined supporting in piem.  That's not because I don't think people
would find it useful; based on discussions on Magit's issue tracker
about git-send-email [2], I believe there's a good amount of interest in
such functionality.  However, I think what particular workflow will work
for a person is likely to vary a lot and depend on several factors, to
the point where a large number of users will end up creating their own
tailored process [3].  My current thinking is that it makes sense to
have dedicated packages that add support for specific workflows, and
that this functionality is orthogonal to functionality for applying
patches.

So, I don't know.  I'm not sure piem is a good home for "send patches"
functionality.

A related, larger issue here is my choice to focus piem on public-inbox
even though many users may only be interested in the functionality for
applying patches.  Working on projects without a public-inbox archive is
supported to some degree [4], and notmuch users can even process patches
with b4, but that just kind of fell together rather than being a goal
(even more so because mailscripts already covered this).  My primary
interest with piem is public-inbox, and there's some very exciting work
upstream on a local client [5] that I plan to support.

Thanks for starting this discussion.


[1] There's also Sean Whitton's mailscripts, which was around before
    piem.  There are some really nice features, including some b4-like
    patch extraction functionality:
    - https://git.spwhitton.name/mailscripts/
    - https://lore.kernel.org/workflows/87lfp38p7s.fsf@iris.silentflame.com/

[2] Here's a relevant comment that links to some past discussions:
    https://github.com/magit/magit/issues/4028#issuecomment-572881356

[3] To use my odd workflow as an example: I prefer to call
    git-format-patch and track the cover letter and patches in a
    dedicated branch.  For rerolls of a series, I overwrite the branch,
    and use its reflog to carry over details I want from the previous
    iterations (e.g., bits of the cover letter, remarks after the commit
    message).  Then I just send it out with a plain git-send-email,
    sometimes with the --in-reply-to and --cc's coming from
    notmuch-show-stash-git-send-email.

    It's not really a workflow I think many people would like.

[4] https://docs.kyleam.com/piem/Applying-patches-without-a-public_002dinbox-archive.html#Applying-patches-without-a-public_002dinbox-archive

[5] https://public-inbox.org/meta/20201215114722.27400-1-e@80x24.org/