Rubén Justo <rjusto@xxxxxxxxx> writes:
>> 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.
OK, as long as we prevent such kinds of questionable combinations
("two multi-commit cherry-picks" was merely an example---I did not
mean that is the only problematic case), I do not see much problem
with it. In any case, teaching "status" how to show such a state
with less information loss, which is the theme of this patch, is not
making things worse---even if some of the states may be nonsense and
should be prevented, "git status" is not the place to do so anyway.
I didn't see if the proposed output from the command makes sense
(yet), but somebody else may already have done so and writing their
reviews on their findings. Let's see if we get any positive reviews
and move it to 'next' after that.
Will queue in the meantime not to lose it in 'seen'.
Thanks.
