| Age | Commit message (Collapse) | Author |
|---|
|
The trailer-related options happen to be grouped together with the
alphabetical sorting of the options setting, but the next commit will
add a trailer option that breaks this pattern. Add a section to keep
them together.
Message-Id: <20220516024041.205178-2-kyle@kyleam.com>
|
|
public-inbox has started to drop dates from its copyright lines,
pointing to the recommendation at
https://www.linuxfoundation.org/blog/copyright-notices-in-open-source-software-projects/
I regularly fail to keep copyright lines up to date, so I'll gladly
follow suit.
While touching these lines, change "all contributors" to "all piem
contributors" to get a bit closer to the variants recommended in the
above article.
|
|
Catch up with some new options and add some older ones that I punted
on earlier. This should cover everything that's in b4 v0.8, hiding
things that are a bit too lore-specific or tailored to command-line
operation.
Message-Id: <20210923023511.269242-1-kyle@kyleam.com>
|
|
A client may mirror and configure inboxes locally. Doing so enables
fast local access to public-inbox-httpd and public-inbox-nntpd. And
with the next pubic-inbox release (v1.7), it will be necessary to set
up local externals for lei.
That can lead to a good amount of information being duplicated between
the piem-inboxes option and ~/.public-inbox/config. To avoid this,
let users set an option to enable collecting information from
public-inbox's configuration.
This relies on code getting the list of inboxes with
piem-merged-inboxes rather than inspecting piem-inboxes directly.
That should be okay because at this point there should be very few
third-party callers. An alternative would be to merge values from the
configuration into the value of piem-inboxes. That'd let callers
continue to inspect public-inboxes, but I'd prefer not to touch the
value of a user option.
Message-Id: <20210610185943.14155-5-kyle@kyleam.com>
|
|
|
|
piem-b4-am-ready-from-mid's docstring doesn't mention that it tries to
download the thread from a piem-inboxes URL before falling back to
letting b4 handle the download. The manual's description is better,
though it makes it sound like the b4 fallback depends on not finding a
URL in piem-inboxes rather than the download being unsuccessful for
whatever reason. Reword the docstring and manual text to hopefully
make things clearer.
Message-Id: <20210524005040.12668-1-kyle@kyleam.com>
|
|
Make piem-gunzip-buffer handle the executable check so that callers
don't have to worry about it.
Message-Id: <20210523214623.31331-4-kyle@kyleam.com>
|
|
piem-download-and-decompress calls url-retrieve-synchronously, checks
for a 200 status, and then manually removes the header. This works
okay, but it'd be good for the error handling to match what's done by
url-insert-file-contents.
Introduce a new macro that largely copies what is done by
url-insert-file-contents. The main difference is that url-insert is
used instead of url-insert-buffer-contents so that the contents can be
inserted literally.
This approach is based on Emacs's 5f9671e57e
(lisp/emacs-lisp/package.el: Fix decoding of downloaded files,
2019-05-18).
Message-Id: <20210523214623.31331-3-kyle@kyleam.com>
|
|
If piem-mid-to-thread-functions fails to generate the thread,
piem-b4--get-am-files tries to download the mbox from the URL
associated with the current buffer. However, it uses the message ID
returned by piem-mid rather than the message ID passed by
piem-b4-am-from-mid. That's not a safe assumption for non-interactive
calls to piem-b4-am-from-mid.
Construct the URL with the message ID passed by piem-b4-am-from-mid,
and skip the download completely if that message ID doesn't match the
one for the current buffer.
Message-Id: <20210523214623.31331-2-kyle@kyleam.com>
|
|
Transient 0.3.0 was just released. Require it, and stop using now
obsolete macros.
Message-Id: <20210222034807.23437-1-kyle@kyleam.com>
|
|
I considered having each contributor keep their own copyright line for
each file up to date (like in Guix), but I don't want to have to
remember to pester patch submitters for that in reviews. Instead go
with a public-inbox-inspired "all contributors".
|
|
|
|
It looks like all other spots that aren't specifically referring to
the header use "message ID".
|
|
I tend to use a few dedicated worktrees for projects and am not
interested in creating a worktree for each patch series I apply.
However, I can imagine wanting to create one every now and then. Make
it possible by adding a prefix argument to piem-am and
piem-b4-am-from-mid that flips the meaning of piem-am-create-worktree.
Message-Id: <20201115061518.22191-6-kyle@kyleam.com>
|
|
As of 30defdb (b4: Clean up temporary directories by default,
2020-09-27), piem-b4-am-from-mid is supposed to clean up its temporary
directory unless piem-b4-keep-temp-directory is non-nil. That commit,
however, missed an error case where the cleanup function needs to be
triggered.
Message-Id: <20201025192111.27439-1-kyle@kyleam.com>
|
|
Each piem-b4-am-from-mid call works in a new temporary directory.
Aside from debugging, there's no reason to keep these directories
around, polluting temporary-file-directory.
Message-Id: <20200927061446.2301-1-kyle@kyleam.com>
|
|
These aren't too useful (and I don't want to duplicate what is or at
least should be in the manual), but they're better than nothing.
|
|
Message IDs can include characters that must escaped before being
included in the path part of public-inbox URLs. Add a variant of
url-hexify-string that uses the same set of characters as
public-inbox's mid_escape().
Message-Id: <20200919044639.26871-2-kyle@kyleam.com>
|
|
When 05f3ca5 (manual: A rough and incomplete start, 2020-08-25)
fleshed out the skeleton a bit, the individual nodes for the
integration libraries got dropped and the one for b4 got renamed.
|
|
I haven't decided how I want to deal with packaging, but in any case
there's no point in having a version heading for each library. Keep
the one in piem.el since there's no *-pkg.el file (at this point, at
least).
|
|
There's no need to have a function like piem-inbox-url for every key.
Drop piem-inbox-url, but keep piem-inbox-coderepo around because it
does a bit of extra processing on top.
Message-Id: <20200828031920.7515-3-kyle@kyleam.com>
|
|
piem-download-and-decompress uses url-retrieve and a callback, setting
url-asynchronous to nil. This approach doesn't seem to be sufficient
because I'm getting intermittent failures in piem-b4--get-am-files
related to unfinished processes. And taking a peek at
url-retrieve-synchronously suggests that indeed a good amount more is
needed to do a synchronous call with url-retrieve.
Switch piem-download-and-decompress over to
url-retrieve-synchronously. I haven't noticed any issues with the
url-retrieve call in piem-inject-thread-into-maildir, but switch that
over too for simplicity and consistency.
Message-Id: <20200828025605.1106-1-kyle@kyleam.com>
|
|
If a call to piem-b4-am-from-mid fails to generate the thread for a
message ID via piem-mid-to-thread-functions, b4 is called without a
local mbox. In this case, b4 tries to download the thread from the
URL specified by b4.midmask in the caller's Git configuration.
That works, but it's inconvenient because the user needs to configure
the URL in two places. If the current buffer is associated with an
inbox in piem-inboxes, try to download the thread from its :url before
falling back to b4's midmask.
Message-Id: <20200817013343.15615-6-kyle@kyleam.com>
|
|
Message-Id: <20200817013343.15615-5-kyle@kyleam.com>
|
|
The sources of mbox patches fed to git-am are 1) threads downloaded
from a public-inbox HTTP instance, 2) mboxes generated via
piem-mid-to-thread-functions, and 3) those generated via
piem-am-ready-mbox-functions. The first source should always be
mboxrd. For the second, piem-notmuch-mid-to-thread is currently the
only function suitable for piem-mid-to-thread-functions, and it uses
mboxrd. The third source is a mix between mbox and mboxrd.
By default, git-am tries to auto-detect the patch format, but let's
explicitly specify --patch-format to avoid any incorrect guesses.
Message-Id: <20200810020704.30150-1-kyle@kyleam.com>
|
|
|
|
This logic will be used in another spot.
|
|
piem-am will become a command that works with mboxes outside of -b4.
In this context, it's easier and cleaner to deal with a buffer than
temporary files.
|
|
The end goal is to turn piem-am into a command that can work with
patches extracted from the current buffer. Pull out the logic that
can be reused for this.
|
|
Directing all piem-related output to one buffer should be sufficient,
for now at least.
|
|
These are things that will be used outside of piem-b4.
|
|
|
|
Conceptually these are under ";;; Code", so add a ";" to reflect that.
|
|
|
|
This option was added in b4 v0.4.1.
|
|
The function for generating the default branch name may need to be
tweaked to give useful suggestions in practice. Let's see.
|
|
When passing a name like "a.mbx" to b4-am's --mbox-name, only the "a"
is retained; b4-am unconditionally appends the ".mbx". Avoid passing
a name with ".mbx" to make it clearer that the caller does not control
the extension.
Reduce the base name to "m" to avoid a message ID ending with ".*"
being treated as an extension, which would require analyzing the
message ID in order to guess what output name b4-am will use.
Finally, name the custom thread mbox with "-piem" rather than
"-thread" (which was chosen to mimic b4-mbox) so it's more obvious who
created the file when later inspecting the directory.
|
|
The subprocess handling needs reworked and polished, so this helper
likely won't stay around in its current form for long, but it's still
useful to send git through it so that a failure signals an error and
shows the output.
|
|
Aside from switching the 'b4 am' process to an asynchronous one, the
am-ready commands may not need a lot of work. The more interesting
variant, piem-b4-am-from-mid, can find an associated code repository
and am the patch, but there's a lot that needs to be fleshed out.
|