Re: [minor BUG] cherry-pick -x doesn't work if a conflict occurs

From: Jay Soffian <jaysoffian@gmail.com>
Date: Jan 5, 2011, 16:28 UTC
Message-ID: <AANLkTimi8s7QRYuEgr2x=bqwEuFPqUUQF4E=f=_PsoV0@mail.gmail.com>
In-Reply-To: <20110105065047.GJ25121@pengutronix.de>

2011/1/5 Uwe Kleine-König <u.kleine-koenig@pengutronix.de>:

>> The man page says -x only takes effect when you do not have a conflict, so there
>> is no bug.
> ah, I wonder if this is intended or just documenting a short-coming :-)

I think it's intended as it's no longer the original commit, but personally I think it should be configurable (I'd like -x to be configurable as well). For now, I use the following "recommit" script after a cherry-pick conflict.

#!/bin/sh # Used after a cherry-pick conflicts to commit with the original # authorship (commit -c) but keep the newly generated commit message # self=$(cd "$(dirname "$0")" && pwd -P)/$(basename "$0") . "$(git --exec-path)/git-sh-setup" require_work_tree cd_to_toplevel test -f .git/MERGE_MSG || die "No .git/MERGE_MSG"

if test "$GIT_EDITOR" = "$self"
then
  cat .git/MERGE_MSG > .GIT/COMMIT_EDITMSG
  exit 0
fi

if sha1=$(sed -ne \
  's/^(cherry picked from commit \([a-f0-9]\{40\}\))$/\1/p' .git/MERGE_MSG)
then
  export GIT_EDITOR="$self"
  git commit -c $sha1
fi

j.