From: Patrick Steinhardt Date: Mon, 15 Sep 2025 09:32:48 GMT Subject: Re: [PATCH RFC v3 02/18] sequencer: add option to rewind HEAD after picking commits Message-ID: In-Reply-To: On Wed, Sep 10, 2025 at 03:04:00PM +0100, Phillip Wood wrote: > 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