aboutsummaryrefslogtreecommitdiff
path: root/Documentation/RelNotes/0.4.0.txt
diff options
context:
space:
mode:
authorKyle Meyer <kyle@kyleam.com>2024-02-04 14:54:47 -0500
committerKyle Meyer <kyle@kyleam.com>2024-02-11 22:37:54 -0500
commit8abe70c235f8c8b77f7fe7f57a56068dd44c905a (patch)
tree78b93432d23b4c1852cb10eeff16a3d25894aa35 /Documentation/RelNotes/0.4.0.txt
parent4256eb8b62f81f1f755184bbe245b3155f723a5a (diff)
downloadpiem-8abe70c235f8c8b77f7fe7f57a56068dd44c905a.tar.gz
*-am-ready-mbox: Don't require PATCH prefixHEADmaster
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 'Documentation/RelNotes/0.4.0.txt')
0 files changed, 0 insertions, 0 deletions