undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

git-gui: Give amend precedence to HEAD over MERGE_MSG

Browse Source 
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>
This commit is contained in:
Shawn O. Pearce 2007-06-11 19:39:55 -04:00
parent 615b865358
commit b2f3bb1b66
1 changed files with 2 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
git-gui.sh
View File

@ -471,7 +471,8 @@ proc rescan {after {honor_trustmtime 1}} {
if {![$ui_comm edit modified]
|| [string trim [$ui_comm get 0.0 end]] eq {}} {
if {[load_message GITGUI_MSG]} {
if {[string match amend* $commit_type]} {
} elseif {[load_message GITGUI_MSG]} {
} elseif {[load_message MERGE_MSG]} {
} elseif {[load_message SQUASH_MSG]} {
}