Re: [PATCH] status: fix branch shown when not only bisecting

From: Rubén Justo <rjusto@gmail.com>
Date: Aug 1, 2023, 20:39 UTC
Message-ID: <32997081-62d8-b900-d58a-308e5c773818@gmail.com>
In-Reply-To: <xmqqedkn3arv.fsf@gitster.g>

On 31-jul-2023 16:45:56, Junio C Hamano wrote:

Show 17 quoted lines

> Rubén Justo <rjusto@gmail.com> writes:
> 
> > In 83c750acde (wt-status.*: better advice for git status added,
> > 2012-06-05), git-status received new informative messages to describe
> > the ongoing work in a worktree.
> >
> > Multiple operations can be performed concurrently in a worktree.  For
> > example, during a rebase, the user can also perform a cherry-pick.
> 
> Hmph ...
> 
> > In
> > that situation, git-status only shows information about one of them,
> > prioritizing which one, in order: merge, am, rebase, cherry-pick.
> 
> ... I have to wonder if it is a bug that "cherry-pick" proceeds when
> there is an ongoing "rebase" going on, though.

Doing an interactive rebase, stop at some point, cherry-pick some commit and let the rebase continue, it's not optimal but does not seem to me to be bad workflow.

Show 6 quoted lines

> When a sequencer is
> driving a cherry-pick of master..topic1 and the user gets control
> back in the middle, perhaps due to a conflict, should the user be
> allowed to do "cherry-pick master..topic2", splicing these commits
> from the other topic in the middle of the first cherry-pick session
> the user started?

We already prevent this to happen. Maybe because we do not want to support multiple .git/CHERRY_PICK_HEAD files. Anyway, to me, sounds like a reasonable thing to have: that nesting limit of 1. The same for the other operations.