From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:863f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms12 with LMTPS id OBcEICNaA2BvVQAAsNZ9tg (envelope-from ) for ; Sat, 16 Jan 2021 21:26:59 +0000 Received: from out1.migadu.com ([2001:41d0:2:863f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id 52EvESJaA2BbcAAA1q6Kng (envelope-from ) for ; Sat, 16 Jan 2021 21:26:58 +0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1610832416; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=HiuKWmv1gK1BtGVSynzgQpZ3PnpLR28DqoCmi0lRhAw=; b=c08LJDffHbJA5MFpFbm3jgUppv8pc42CtVXXZyUSxnIi0QyPxqca9PqnOU2A9KRRZQHXAc ZVjY1PIykfvXrS6Y7l+Rn/Up2EAOUqGPMokKgjb/m3gBR6BfsOFtFT+x6w57yeGZxrTTW1 t4MQOu+jMsHRFjfaS1xb7xvv7eDt7OJRlgZu8TIvIgA/4GXcytl4hMby61PojPz+Rfoc6v 6aTWxS6idS14oMhrx4IgRI9z2J+bABsH72TQxe9uU7JuuvfQLlmh3oxR8ZHXB/u72I3Dcr DLisUZXTHJNtFigNQCsYZscCOwtW/3Yj/9qvz1z4WxqBncS2684GnYHD1IB6ag== From: Kyle Meyer To: Xinglu Chen Cc: piem@inbox.kyleam.com Subject: Re: Merge projects? In-Reply-To: <87eeil8a3m.fsf@yoctocell.xyz> Date: Sat, 16 Jan 2021 16:26:53 -0500 Message-ID: <87y2gs374y.fsf@kyleam.com> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: kyle@kyleam.com X-TUID: I1ZKMJ4XRZpd 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/