Danny Lin <danny0838@xxxxxxxxx> writes: > Previous case does not correctly check the "p ..." pattern. > > Signed-off-by: Danny Lin <danny0838@xxxxxxxxx> > --- > contrib/completion/git-prompt.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh > index db7c0068fb..8ae341a306 100644 > --- a/contrib/completion/git-prompt.sh > +++ b/contrib/completion/git-prompt.sh > @@ -315,7 +315,7 @@ __git_sequencer_status () > elif __git_eread "$g/sequencer/todo" todo > then > case "$todo" in > - p[\ \ ]|pick[\ \ ]*) > + p[\ \ ]*|pick[\ \ ]*) > r="|CHERRY-PICKING" > return 0 > ;; It is obvious that the original code is *not* prepared to see 'p' followed by whitespace followed by other things, but I am not sure how the code in sequencer.c::todo_list_write_to_file() can choose to pass flags & TODO_LIST_ABBREVIATE_CMDS to todo_list_to_strbuf(). Danny, do you have a reproduction recipe, preferrably one you can turn into a new test in t9903-bash-prompt.sh? Or was this found merely by inspecting the code? Dscho, as far as I can tell, builtin/rebase.c can set the bit in the flags word when rebase.abbreviatecommands configuration is set, but that configuration variable is about rebase and it shouldn't affect how multi-step cherry-pick would work, should it? I am wondering if an uninitialized "flags" word, whose TODO_LIST_ABBREVIATE_CMDS bit randomly was turned on, caused todo_list_to_strbuf() to write an abbreviated insn in the todo file. If so, the insn word being abbreviated or fully spelled out would not affect the correctness, but the flags word affects other things that are more crucial to correctness, so... Thanks.
