From: Kyle Meyer <email@example.com> To: Xinglu Chen <firstname.lastname@example.org> Cc: email@example.com Subject: Re: Merge projects? Date: Sat, 16 Jan 2021 16:26:53 -0500 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.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, 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 , 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 , 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 . 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 , 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  that I plan to support. Thanks for starting this discussion.  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://firstname.lastname@example.org/  Here's a relevant comment that links to some past discussions: https://github.com/magit/magit/issues/4028#issuecomment-572881356  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.  https://docs.kyleam.com/piem/Applying-patches-without-a-public_002dinbox-archive.html#Applying-patches-without-a-public_002dinbox-archive  https://email@example.com/
next prev parent reply other threads:[~2021-01-16 21:26 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-16 10:11 Xinglu Chen 2021-01-16 21:26 ` Kyle Meyer [this message] 2021-01-17 10:48 ` Xinglu Chen
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://git.kyleam.com/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: Merge projects?' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.kyleam.com/piem/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).