From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:203:b4db::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms12 with LMTPS id EK5FEF70zGHHXwAAsNZ9tg (envelope-from ); Wed, 29 Dec 2021 23:50:54 +0000 Received: from out0.migadu.com ([2001:41d0:2:267::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id mzV/D170zGFf3wAA9RJhRA (envelope-from ); Thu, 30 Dec 2021 00:50:54 +0100 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kyleam.com; s=key1; t=1640821854; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=CL3QdYmv5a7C0xwhh1mk2uAdMAQ3vpU88jmm7XqxTFM=; b=UXRRWCE+FSd5FWwISTNMPDoJETDhOVYGRjmhbS9g5awPop5lDIrybXeH5tNkswaO5Ctd+9 fz82+M0L6mcqkJums9NwpULfCoaJZZmhHPzJn+3EDz/lewbVVwlPKRJMOs2vZHbOQT4XFg qzxa2s+zXQXzDyeTIuGP5VEeKGXMbahWbGDbmjFjnRA2zE02RNd+T2RG1MRw74khjrpr3X d0q3WiNNx4LJFMYCwYllZMkts2QJvnJD1hOGzPr/ewlPFRi3I6oHskti6CaPBB4npMNWjx suVJsXN7HpSKqLKGnUkvb53wPTcEaboOAtesFSCYOviQPnzduiucxjcOoJ33LA== From: Kyle Meyer To: piem@inbox.kyleam.com Subject: [RFC PATCH 00/14] am, b4-am: Add commands to extend an existing branch Date: Wed, 29 Dec 2021 18:50:22 -0500 Message-Id: <20211229235036.372313-1-kyle@kyleam.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: kyleam.com X-TUID: JMrOJFAXKROu Every now and then I think that it'd be nice to have commands that extend an existing branch rather than create a new one. But then I end up concluding that most of the time I really do want to create a new branch; for the other times, it's pretty easy to instead apply to a detached head and then merge that into the target branch (e.g., with magit-merge-into). I had the thought again recently and decided to see how going in this direction looked. The result is this somewhat raw series (at the very least, names and key bindings probably need more thought, and the manual needs an update). Patches 7, 12, 13, and 14 are the main user-facing changes. I'm still undecided about the overall direction at this point, though I plan to at least extract and modify some patches from this series. I have the feeling that the piem-am functionality is bound to be moved under a transient at some point to give provide real estate for new functionality. That might be a good reason to take some of the prep patches, though that shouldn't be the sole reason for adding these new "extend existing branch" variants. Note that, in piem's pre-1.0 release state, I am not considering backwards compatibility as a reason to avoid these changes. [ 1/14] am: Give better name to default piem-am-read-worktree-function value [ 2/14] am: Add dedicated function for reading worktree [ 3/14] am: Extract git-am logic to dedicated function [ 4/14] am: Add function for reading piem-am's arguments [ 5/14] am: Add comment header for patch editing subsection [ 6/14] edit patch: Inject values via interactive arguments [ 7/14] am, b4-am: Rename piem-am to piem-am-create [ 8/14] am, b4-am: Rewrite -create docstrings to emphasize branch creation [ 9/14] piem-am-create: Move info argument to the end [10/14] piem-am--arguments: Make info extraction optional [11/14] b4: Move logic for checking arguments to a dedicated function [12/14] am, b4-am: Add commands that extend an existing branch [13/14] am: Move functionality under a dedicated transient [14/14] b4: Add piem-b4-am-from-mid-extend to transient Documentation/piem.texi | 51 +++++++------ piem-b4.el | 65 ++++++++++------ piem.el | 159 ++++++++++++++++++++++++++-------------- 3 files changed, 174 insertions(+), 101 deletions(-) base-commit: afa9e05e5bb42d88b0c5cf79bdcb8fbd14fdd800 -- 2.34.0