[RFC/PATCH 0/2] CHERRY_HEAD

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(-)