Jay Soffian noticed that we give "git reset HEAD <path>" as an instruction to get rid of the local change that has already been added to the index even when <path> is unmerged, or it is merged and we are about to commit a merge. In neither case, "git reset HEAD <path>" is absolutely a wrong thing to do while merging. This miniseries updates the advices given in status/commit. It applies on top of the jk/1.7.0-status topic, and has trivial conflicts in wt-status.c with the jk/unwanted-advices topic that has already graduated to 'maint'. Junio C Hamano (3): commit/status: check $GIT_DIR/MERGE_HEAD only once commit/status: "git add <path>" is not necessarily how to resolve status/commit: do not suggest "reset HEAD <path>" while merging builtin-commit.c | 12 ++++++------ t/t7060-wtstatus.sh | 3 +-- wt-status.c | 16 +++++++++++----- wt-status.h | 1 + 4 files changed, 19 insertions(+), 13 deletions(-) -- 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