Re: [PATCH RFC v3 02/18] sequencer: add option to rewind HEAD after picking commits
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Sep 15, 2025, 09:32 UTC
- Message-ID
- <aMfdQFYdL1xoHADp@pks.im>
- In-Reply-To
- <f74b9dfe-b05c-431e-8872-92e2bbb75b8c@gmail.com>
On Wed, Sep 10, 2025 at 03:04:00PM +0100, Phillip Wood wrote:
Show 23 quoted lines
> Hi Patrick > > On 04/09/2025 15:27, Patrick Steinhardt wrote: > > While the sequencer infrastructure knows to rewind "HEAD" to whatever it > > was pointing to before a rebase, it doesn't do the same for non-rebase > > operations like cherry-picks. This is because the expectation is that > > the user directly picks commits on top of whatever "HEAD" points to, and > > we advance the reference pointed to by "HEAD" instead of updating it > > directly. > > > > We're about to introduce a new command though that needs to detach > > "HEAD" while being more similar to git-cherry-pick(1) rathen than to > > git-rebase(1). As such, we'll want to restore "HEAD" to point to the > > branch that we started on while not using the more heavy-weight rebase > > machinery. > > > > Introduce a new option `restore_head_target` to do so. Persist the > > option into the sequencer configuration so that it persists across > > different processes, e.g. when we need to stop due to a merge conflict. > > As with the last patch, can we use this new option in "git rebase"? The > sequencer is already a nest of conditionals, it would be nice to minimize > the number of new ones.
You probably refer to the condition in `sequencer_pick_revisions()` here? Everything else is basically new code.
Honestly, I don't dare touching that condition -- it's already quite complex, and I wouldn't be surprised if changing it in any way would cause regressions.
Patrick