konglu@xxxxxxxxxxxxxxx writes: > Junio C Hamano <gitster@xxxxxxxxx> 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": OK, then I agree that "resolve and do X" is a sufficient level of detail for these messages. >> 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. OK, so this part still needs a bit more work, then. Thanks. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html