Subject: Re: [PATCH RFC v3 02/18] sequencer: add option to rewind HEAD after picking commits

From: Patrick Steinhardt <[email-masked]>
Date: Mon, 15 Sep 2025 11:32:48 +0200

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