On 31-jul-2023 16:45:56, Junio C Hamano wrote: > Rubén Justo <rjusto@xxxxxxxxx> 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. > 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.
