Matthieu Moy a écrit : >> + if (state->merge_in_progress) >> + merge_in_progress_show(s, state, state_color); >> + else if (state->am_in_progress) >> + am_in_progress_show(s, state, state_color); >> + else if (state->rebase_in_progress || >> state->rebase_interactive_in_progress) >> + rebase_in_progress_show(s, state, state_color); >> + else if (state->cherry_pick_in_progress) >> + cherry_pick_in_progress_show(s, state, state_color); >> + if (state->bisect_in_progress) >> + bisect_in_progress_show(s, state, state_color); > > I still disagree with the "else if" logic here. If the user started two > operations, I think we should show both messages. We show both messages in the case of bisect. However, we decided to implement a priority for the other cases because of how the code figures out the current state. The cases in which you're in 'am' AND 'rebase' or only in 'am' is hard to handle. Thus The priority is given to the 'am' because running 'am' during a 'rebase' is possible (and the other way is not). On top of that, I think that the user only needs to know his "most recent" current state. Given that he's running 'am' during a 'rebase', knowing that he's in am progress is enough. If he finishes the 'am', then he will still know that he's in a 'rebase' with 'git status'.