summaryrefslogtreecommitdiff
path: root/lib/blame.tcl
diff options
context:
space:
mode:
authorLibravatar Shawn O. Pearce <spearce@spearce.org>2007-06-11 19:39:55 -0400
committerLibravatar Shawn O. Pearce <spearce@spearce.org>2007-06-11 19:48:41 -0400
commitb2f3bb1b66d9422aa5049f994c6e370a18d89759 (patch)
tree6dd1b8fcf920b362aa4abedee45348d50afa51d7 /lib/blame.tcl
parentgit-gui: Include 'war on whitespace' fixes from git.git (diff)
downloadtgif-b2f3bb1b66d9422aa5049f994c6e370a18d89759.tar.xz
git-gui: Give amend precedence to HEAD over MERGE_MSG
Apparently git-commit.sh (the command line commit user interface in core Git) always gives precedence to the prior commit's message if `commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists. We actually were doing the same here in git-gui, but the amended message got lost if $GIT_DIR/MERGE_MSG already existed because we started a rescan immediately after loading the prior commit's body into the edit buffer. When that happened the rescan found MERGE_MSG existed and replaced the commit message buffer with the contents of that file. This meant the user never saw us pick up the commit message of the prior commit we are about to replace. Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by running `git cherry-pick -n $someid` and then trying to amend the prior commit in git-gui, thus combining the contents of $someid with the contents of HEAD, and reusing the commit message of HEAD, not $someid. With the recent changes to make cherry-pick use the $GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message of $someid, not HEAD. Now we always use HEAD if we are amending. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Diffstat (limited to 'lib/blame.tcl')
0 files changed, 0 insertions, 0 deletions