Re: [PATCHv6 1/4] wt-status.*: better advices for git status added

> Junio C Hamano <gitster@pobox.com> a écrit:
> ...
>>
>> Also when you are in the middle of "git am -3", there may be
>> unmerged entries in the index; do we want to suggest "add/rm" to
>> resolve to fill in the missing detail of "fix" in your "when you
>> have fixed this problem" message?
>>
>> We may want to decide how detailed we want to make the help texts;
>> the same fuzziness exists in "fix conflicts and then" at the
>> beginning of show_rebase_in_progress().
>
> In fact, to detail more "fix" in this case by suggesting "add/rm"
> would be repetitive, as this advice is already given under the block
> "unmerged paths":

>> This last "else" block is taken when running "rebase -i" and there
>> is no longer any unmerged index entry.  I wonder if the message from
>> the first printf_ln needs to be clarified further depending on the
>> context.
>>
>> Specifically, in this sequence:
>>
>> 	- the user marked a commit as "pick";
>>         - replaying of that commit resulted in conflicts;
>>         - the user edited files and used add/rm to resolve conflicts;
>>         - the user did one of these:
>> 	  1. "git status"
>>           2. "git commit" without "--amend"
>>           3. "git commit --amend"
>>
>> can this message come up?
>>
>> In such a case, "You are currently editing a commit" is actively
>> wrong.  The user has finished resolving the conflict and are about
>> to record the result.  Also, "git status" and "git commit" without
>> "--amend" are both sensible commands in this situation, but running
>> "git commit --amend" is likely to be a mistake, no?
>
> True, the last "else" block is not supposed to be taken. The correct
> message that should be displayed is the first "else if" block, saying
> just that all conflicts are fixed and to run rebase --continue.