diff options
author | Kyle Meyer <kyle@kyleam.com> | 2024-02-04 14:54:47 -0500 |
---|---|---|
committer | Kyle Meyer <kyle@kyleam.com> | 2024-02-11 22:37:54 -0500 |
commit | 8abe70c235f8c8b77f7fe7f57a56068dd44c905a (patch) | |
tree | 78b93432d23b4c1852cb10eeff16a3d25894aa35 /COPYING | |
parent | 4256eb8b62f81f1f755184bbe245b3155f723a5a (diff) | |
download | piem-8abe70c235f8c8b77f7fe7f57a56068dd44c905a.tar.gz |
All of the *-am-ready-mbox functions expect inline patches to have a
'[... PATCH ...]' in the subject. In cases where a patch is sent
without that prefix, a piem-am caller gets an unhelpful "Could not
find am-ready mbox for current buffer" in response to
piem-am-ready-mbox returning nil.
To support these (hopefully rare) cases, drop the "has patch prefix?"
guard from all the *-am-ready-mbox functions. A caller is requesting
to extract a patch from the current buffer, and the "is the current
buffer in the right mode?" check should be sufficient for an
am-ready-mbox function to decide whether it should be responsible for
generating the mbox.
This added flexibility increases a caller's ability to apply invalid
patches. As with the previously possible cases, the output buffer
will give a clear error, but the caller will need to abort the git-am
sequence and clean up the branch. That seems reasonable given that,
in addition to the initial explicit request, an interactive piem-am
caller needs to "confirm" applying through the prompts, making it more
difficult to get to that state unintentionally.
Reported-by: Leo <git@relevant-information.com>
Link: https://inbox.kyleam.com/piem/87fry9hn9u.fsf@
Message-ID: <87ttmo57js.fsf@kyleam.com>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions