Merge projects?

Merge projects?

[Xinglu Chen]

Hi,

I recently discovered piem and find it very interesting.  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.  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?

[0]: https://sr.ht/~yoctocell/git-email/


Regards,
Xinglu

Re: Merge projects?

[Kyle Meyer]

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/

Re: Merge projects?

[Xinglu Chen]

On Sat, Jan 16 2021, Kyle Meyer wrote:

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

Good point, it seems like everyone has a slightly different workflow when
using git-format-patch and git-send-email.  

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

Yeah, it is probably better for something like Magit or VC to offer this
functionality.

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

This looks exciting, I would love to see an interface for lei, this
would make it much faster than using Gnus over NNTP.

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

Thanks for explaining your workflow and pointing out
`notmuch-show-stash-git-send-email`, I will definitely make use of it in
the future.

--
Xinglu Chen