The user-experience after a cherry-pick conflicts is suboptimal. The user has two choices for committing the resolved state: 1. To retain the original authorship and commit message, the user can 'git commit -c <original commit id>'. This is what cherry-pick itself advises. In this case MERGE_MSG (generated during the cherry-pick) is ignored. That's bad since MERGE_MSG contains the list of conflicts which is nice to have in the new commit. If 'cherry pick -x' was used, the -x annotation is lost. Asking the user to remember the original commit id is also a bit harsh. 2. To reset the authorship, the user can 'git commit'. This will use the MERGE_MSG, but the original authorship is lost. We fix both of these issues by recording the original commit in CHERRY_HEAD if a conflict occurs during cherr-pick. We teach commit to use CHERRY_HEAD to retrieve the original authorship (unless --reset-author is used), but take the commit message from MERGE_MSG. A further improvement would be to teach cherry-pick --continue and --abort options a la rebase, but I think that should be prototyped in shell-script. Jay Soffian (2): Introduce CHERRY_HEAD Teach commit to handle CHERRY_HEAD automatically Documentation/git-commit.txt | 7 +++-- branch.c | 1 + builtin/commit.c | 36 ++++++++++++++++++++++++++----- builtin/revert.c | 20 ++++++++++++++++- contrib/completion/git-completion.bash | 2 + 5 files changed, 55 insertions(+), 11 deletions(-) -- 1.7.4.5.g9affb -- 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