Re: This is how you import a mailing list archives (e.g. guix-patches) into mu4e
zimoun writes: > I fetch from yhetil.org (Git) and then convert to MailDir because I use > Notmuch as indexer (and reader :-)). And I do not want to duplicate the > storage. Therefore, after fetching and converting, the Git repo is > garbage collected, > > --8<---cut here---start->8--- > echo $head > $gitdir/shallow > $git gc --quiet --prune=all > --8<---cut here---end--->8--- > > https://gitlab.com/zimoun/my-conf/-/blob/master/.local/bin/sync-public-inboxes.sh#L94-99 > > For instance, the current size of guix-patches on my machine is 152K > compared to the complete guix-patches Git repo of 277M. Nice. Maintaining a shallow clone certainly makes sense. > Well, I have not investigated much with ’grokmirror’ and > ’public-inbox-fetch’ and maybe it would also work smoothly with the same > trick; avoiding many manual plumbing. I haven't used it myself (unsurprisingly I have an interest in keeping yhetil.org's inboxes replicated on my local machine), but I think you can keep grokmirror clones shallow by hooking up its grok-pi-piper to the post-update hook. Here's a relevant bit from grokmirror's docs: --8<---cut here---start->8--- [DEFAULT] # To start piping public-inbox messages into your inbox, simply # install procmail and add the following line to your ~/.procmailrc: # DEFAULT=$HOME/Maildir/ # You can now read your mail with "mutt -f ~/Maildir/" pipe = /usr/bin/procmail # Once you've successfully piped the messages, you generally # don't need them any more. If you set shallow = yes, then # the repository will be configured as "shallow" and all succesffully # processed messages will be pruned from the repo. # This will greatly reduce disk space usage, especially on large archives. # You can always get any number of them back, e.g. by running: # git fetch _grokmirror master --deepen 100 shallow = yes --8<---cut here---end--->8---
Re: This is how you import a mailing list archives (e.g. guix-patches) into mu4e
On 12/05/22 09:45:41 +0100, zimoun wrote:
> Personally, I use “git clone” from a public-inbox instance [1].
>
> git clone --mirror https://yhetil.org/guix-patches/1 \
> guix-patches/git/1.git
>
> where ’1’ can be also replace by ’0’ for the very old ones.
In the case of guix-patches, there's not a 0.git. I started it at 1.git
to leave open the possibility of adding 0.git with the messages I was
missing from the beginning of the list's history (from Feb 12, 2017 to
March 27, 2017). I'm not sure I'm ever going to do so at this point
and, even if I did, reserving 0.git doesn't have much advantage over
just adding the old messages on top of the existing epoch, so I probably
should have just started it at 0.git.
> Then the conversion from Git commit to maildir is done by a small script
> [2], where all the job reads:
>
> --8<---cut here---start->8---
> # Extract the message from each commit in the range and store it
> # in the Maildir for notmuch to consume.
> $git rev-list $range | while read sha; do
> # : fatal: path 'm' does not exist in
> # and it can also raise issues with notmuch, as:
> # Note: Ignoring non-mail file: $maildir/new/$sha
A tree can either have m or d ("deleted" messages):
https://public-inbox.org/public-inbox-v2-format.html
So you should be able to avoid this error by skipping d's.
> $git show $sha:m > $maildir/new/$sha
> done
> --8<---cut here---end--->8---
>
> (Maybe better could be done and more robust are around.)
No need to change what works, of course, but
https://public-inbox.org/clients.html mentions l2md and impibe as tools
for converting public-inbox archives to Maildir.
* https://git.kernel.org/pub/scm/linux/kernel/git/dborkman/l2md.git
* https://leahneukirchen.org/dotfiles/bin/impibe
In terms of cloning archives, plain cloning and fetching with Git is
fine, but, if you have public-inbox locally, you can instead use
public-inbox-clone and public-inbox-fetch, which will handle some
details for you (e.g, cloning underlying epochs and recognizing that new
epochs have been added):
$ public-inbox-clone https://yhetil.org/guix-patches
Another option for fetching that's nice if you're mirror multiple repos
is grokmirror:
* https://git.kernel.org/pub/scm/utils/grokmirror/grokmirror.git/about/
* example setup for guix:
https://yhetil.org/guix-patches/878scww903@kyleam.com/
Both grokmirror and public-inbox-clone/fetch make use of the manifests
that are published for public-inbox archives:
$ curl -fSsL https://yhetil.org/manifest.js.gz | gzip -d | \
jq -r 'keys | .[] | select(contains("guix"))'
/guix-bugs/git/0.git
/guix-devel/git/0.git
/guix-patches/git/1.git
/guix-science/git/0.git
/guix-user/git/0.git
Then there's of course also public-inbox's lei (local email interface).
I won't get into that, but, for anyone interested, here are messages
where I've given some examples:
* https://yhetil.org/emacs-devel/87wnh22w7o@kyleam.com
* https://yhetil.org/guix-devel/87y1zcljq3@kyleam.com
Re: Exporting patches without prerequisite patch id
kiasoc5 writes: > I have some commits on my local guix repo like this: > > (master) HEAD -> A -> B -> C > > When I do `git format-patch -3 --base=auto` I get prerequisite patch > ids in some of the patches. But I want to each patch to depend only on > HEAD. In other words I want to export patches like so: > > HEAD -> A > HEAD -> B > HEAD -> C > > How do I do this? `git-format-patch --base` doesn't support lying about the state by leaving out the prerequisite patch IDs, as far as I know. If you have a string of commits that you want to post as single patches where only base-commit is listed, the approach would be to split each of those off into separate, independent branches on top of the base commit. a / base - b \ c
Re: Using emacs library with guix environment
jgart writes: > I'm only able to properly source the library into the environment if I run > the following: > > `guix environment emacs-commander --ad-hoc emacs-commander` > > Why do I have to provide emacs-commander twice to the environment command? I believe the key package that the first emacs-commander (the one before --ad-hoc) brings in is emacs along with its corresponding EMACSLOADPATH. Notice that $ guix environment --pure --ad-hoc bash emacs-commander -- sh -c 'echo $EMACSLOADPATH' outputs nothing. Now if emacs is added as an ad-hoc package: $ guix environment --pure --ad-hoc bash emacs-commander emacs -- sh -c 'echo $EMACSLOADPATH' /gnu/store/qg6rsw6w587aykln2dzssr43nl6jq1a1-profile/share/emacs/site-lisp Or another test, dropping --pure to be closer to your initial snippet: $ guix environment --ad-hoc emacs-commander -- \ emacs -Q --batch --eval '(print (locate-library "commander"))' nil # add emacs as ad-hoc package $ guix environment --ad-hoc emacs-commander emacs -- \ emacs -Q --batch --eval '(print (locate-library "commander"))' "/gnu/store/kr9cnw5c9nydiilb25w3q5bnp5c1zvca-emacs-commander-0.7.0/share/emacs/site-lisp/commander-0.7.0/commander.elc"
Re: Workflow with mu4e + magit for sending patchsets to guix?
Pierre Neidhardt writes:
> --8<---cut here---start->8---
> (defvar ambrevar/known-mailing-list-archives
> '(("help-guix@gnu.org" . "guix-user")
> ("guix-de...@gnu.org" . "guix-devel")
> ("debbugs.gnu.org" . "guix-bugs"))
> "Alist of mail adresses and their Yhetil name.
[...]
Thanks.
> Note that I've set two entries, one that prefer guix-patches over
> guix-bugs because they seem to use the same recipient domain
Eric Wong has been working on adding an "external index" to public-inbox
that allows operating on a collection of inboxes.
https://public-inbox.org/meta/20201027075453.19163-...@80x24.org/
https://public-inbox.org/meta/20201126194543.GA30337@dcvr/
The feature is still being cooked, but I got around to trying it out
this weekend, and it seems to work nicely.
Anyway, that feature helps here because it allows all Guix-related lists
to be exposed under a single inbox. You can now construct a URL without
worrying about which particular list the message is from:
https://yhetil.org/guix/87k0u8v42a@ambrevar.xyz
Re: Workflow with mu4e + magit for sending patchsets to guix?
zimoun writes: > On Mon, 16 Nov 2020 at 21:36, Kyle Meyer wrote: > >>> 4. !! send-email --to=guix-patc...@gnu.org -cover-letter.patch >>> 5. Wait and refresh my inbox >>> 6. !! send-email --to=12...@gnu.org 000?-*.patch >> >> Yeah, 4-6 are tricky and debbugs-specific. For other projects, it could >> just be 'send-email *.patch' once sendemail.to is configured to point to >> the list's address. >> >> For 6, using '--no-thread --in-reply-to=...' will retain the same >> threading you'd see if you weren't using debbugs (i.e didn't have to do >> the two-step send). [...] > To me, today the main annoyance is the selection of the patches at the > step #6. For example, avoid to resend unrelated patches, as: > > - 000?-*.patch could resend the -cover-letter.patch > - *.patch could resend -cover-letter.patch and 0001-Foo-bar.patch > if I am currently sending v2-0001-Foo-bar.patch > - any previous patchset remaining. Yeah, I agree about that being the most annoying aspect, but I'd say that core problem comes from the need for a two-step send. That's a quirky enough divergence from the standard workflow that I think any solution/helper here is unlikely to be in the scope of Magit. But that doesn't mean I don't think it'd be nice to come up with a helper. > Recent example inside my > guix-artwork checkout: > --8<---cut here---start->8--- > -cover-letter.patch > 0001-website-Add-conference-announcement.patch [...] > 0001-website-Update-manifest.patch > tiny.patch > v2-0001-website-Add-conference-announcement.patch [...] > v4-0001-website-Release-conference-schedule.patch > --8<---cut here---end--->8--- > > That’s why time to time I create an output directory and put the series > in. But the -cover-letter.patch (or vN--cover-letter.patch) is > still annoying because it blocks the simple *.patch. Nothing simpler > than * could be done, I see you regexp integrist. :-) Yeah, I'd guess a directory per topic and version is pretty common to make selecting the patches simply DIR/* (again, assuming a normal one-step send-email process). > I am thinking loud. One option (some setq) could be added to Magit > format-patch, and do under the hood: > > - create -cover-letter.patch in the root directory > - create folder v1 (default), otherwise v2 … vN and put the series >in. > > This would be configurable via Magit variables, say: > > magit-send-email-workflow t > magit-format-patch-directory-prefix “v” As I said, I'm not sold on this being something that fits Magit proper, but I'll help write a helper :) > Then, the sequence, > > W C-m l C-m c > W C-m v2 c > W C-m l C-m v3 c > > would produce the final tree: > > + > +- .git > +- -cover-letter.patch > +- v3--cover-letter.patch > +- v1 > +- 0001-Foo-Bar.patch Here's a command that gets you close to that layout. It adds an additional "/" directory on top of the structure you show above. The name is reads from the caller (with a default completion value of the current branch name). It also depends on the caller having an upstream branch set (which I think is a good thing), but you could rework it to avoid it. --8<---cut here---start->8--- (defun my/magit-patch-create-split-directory (name &optional args files) "Create patches in a split layout. Call `git format-patch ARGS -- FILES`, splitting the cover letter off from the main patches. A standard format-patch calls creates a layout like -cover-letter.patch 0001-commit-1-subj.patch 0002-commit-2-subj.patch ... in the directory specified by `--output-directory=' or the current directory. This command expands the structure as NAME |-- -cover-letter.patch `-- vN |-- 0001-commit-1-subj.patch |-- 0002-commit-1-subj.patch where NAME is a name for the series and N is the version specified via `--reroll-count='. The cover letter will have a \"vN-\" prefix after the first version. The motivation for the above layout is to make it easier to send the cover letter to a Debbugs list and, once a bug number is assigned, follow up with the remaining patches: $ git send-email --to=$debbugs-list NAME/-cover-letter.patch $ # [ wait for mail ] $ git send-email --to=$bug-address-from-mail \\ --in-reply-to=$cover-letter-message-id --no-thread NAME/vN/*" (interactive (cons (read-string "Series name: " nil nil (magit-get-current-branch)) (let ((args (transien
Re: Workflow with mu4e + magit for sending patchsets to guix?
Kyle Meyer writes: >> C-m l > > If you follow the convention of writing a cover letter only for > multi-patch series, you can drop the 'C-m l' because by default git will > generate a cover letter when there is more than one commit. Sorry, I was mistaken: generating a cover letter for a multi-patch series is _not_ git's default behavior. That requires setting format.coverLetter to "auto" in your git configuration.
Re: Workflow with mu4e + magit for sending patchsets to guix?
zimoun writes:
> Hi Chris
>
> +CC Kyle since they probably knows the status [1].
Sorry, I have no good news for you :/
> On Mon, 16 Nov 2020 at 15:28, Christopher Lemmer Webber
> wrote:
>
>> I've been making patchset series of emails to guix-patches manually.
>> I'm sure this is the wrong thing to do. I use mu4e + magit and know
>> others have a similar setup.
>>
>> What do you all do?
>
> I am sending really few patches so my workflow is probably not
> optimized. What I do is from magit-status:
>
> 1. Select the commits
I'd suggest always setting an upstream for topic branches. Then the
range you're interested in is almost always "@{upstream}.." (which can
be shortened to "@{u}.."). Or you can add something like this to
Magit's popup [1]:
;;
https://git.kyleam.com/emacs.d/tree/lisp/km-magit.el?id=928629a9ccd8b439d0e98d9976b75c4cf5f048f9#n836
(defun km/magit-patch-create-from-upstream (&optional args)
(interactive (list (transient-args 'magit-patch-create)))
(if-let ((upstream (magit-get-upstream-branch)))
(apply #'magit-run-git "format-patch" upstream args)
(user-error "No upstream branch")))
(transient-append-suffix 'magit-patch-create "c"
'("u" "@{upstream}.." km/magit-patch-create-from-upstream))
Most of my magit customizations never find their way upstream (they tend
to be very tailored to me), but something like the command above would
probably be good to add.
> 2. W c
> C-m b origin/master RET
Yay, base commit :) Note that with the upstream set, you can select
"auto" here. Or you can configure format.useAutoBase to "whenAble" and
not bother setting the option for each invocation.
> C-m l
If you follow the convention of writing a cover letter only for
multi-patch series, you can drop the 'C-m l' because by default git will
generate a cover letter when there is more than one commit.
> c
> 3. Edit the cover letter
> 4. !! send-email --to=guix-patc...@gnu.org -cover-letter.patch
> 5. Wait and refresh my inbox
> 6. !! send-email --to=12...@gnu.org 000?-*.patch
Yeah, 4-6 are tricky and debbugs-specific. For other projects, it could
just be 'send-email *.patch' once sendemail.to is configured to point to
the list's address.
For 6, using '--no-thread --in-reply-to=...' will retain the same
threading you'd see if you weren't using debbugs (i.e didn't have to do
the two-step send).
Also, not helpful for mu4e users, but since I know simon uses notmuch...
notmuch has a really handy notmuch-show-stash-git-send-email. I have a
variant for step 5 above. If you call it visiting the acknowledgment
message, it will copy
--to="nn...@debbugs.gnu.org" --in-reply-to="message-id"
to your kill ring.
https://git.kyleam.com/emacs.d/tree/lisp/km-mail.el?id=928629a9ccd8b439d0e98d9976b75c4cf5f048f9#n225
> AFAIK, there is no ’send-email’ support with Magit. [...]
>
> What I have understood is that Magit-forge should implement ’send-email’
> as a backend (forge) but it has not happened yet. Or I missed the
> news. :-)
Right, there's no send-email support in Magit (or any of the extensions
under its organization). I of course can't speak for Jonas, but I'm not
aware of any movement or concrete plans on that front. I think the most
recent thread to touch on this is actually the one you opened early this
year about extending format-patch options:
.
And, sadly I guess, my view is still similar to what I said there:
send-email has of course come up a number of times before (gh-1756 and
gh-1800 are the most relevant, I think), and tackling that requires a
vision that I don't really have. Perhaps due to a lack of
imagination, I can't think of an implementation on Magit's side that
would improve the simple send-email command that I run. In terms of
sending mail, the most involved thing that I need to do is get the
--to/--ccs and --in-reply-to from an existing thread, but in my view
that's outside of Magit's scope.
I don't know. Maybe I should try to think harder about it.
A final note of hope: as a lurker on the notmuch list, I've noticed that
Jonas has starting doing some patch-based contributions. So, perhaps
he'll get an itch and do his amazing Jonas thing.
