summaryrefslogtreecommitdiff
path: root/git-merge.sh
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2006-12-31 23:21:50 -0800
committerJunio C Hamano <junkio@cox.net>2007-01-01 14:35:16 -0800
commitd1014a1745a8aa90c8de2a5ac7624d8175f96724 (patch)
treef70bf896fec309c221cd9b7b5073f5e87d32eab5 /git-merge.sh
parent9d0524d42f340fc49f9e175d966afb7dce3854bb (diff)
downloadgit-d1014a1745a8aa90c8de2a5ac7624d8175f96724.tar.gz
fail pull/merge early in the middle of conflicted merge
After a pull that results in a conflicted merge, a new user often tries another "git pull" in desperation. When the index is unmerged, merge backends correctly bail out without touching either index nor the working tree, so this does not make the wound any worse. The user will however see several lines of messsages during this process, such as "filename: needs merge", "you need to resolve your current index first", "Merging...", and "Entry ... would be overwritten by merge. Cannot merge.". They are unnecessarily alarming, and cause useful conflict messages from the first pull scroll off the top of the terminal. This changes pull and merge to run "git-ls-files -u" upfront and stop them much earlier than we currently do. Old timers may know better and would not to try pulling again before cleaning things up; this change adds extra overhead that is unnecessary for them. But this would be worth paying for to save new people from needless confusion. Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'git-merge.sh')
-rwxr-xr-xgit-merge.sh3
1 files changed, 3 insertions, 0 deletions
diff --git a/git-merge.sh b/git-merge.sh
index ba42260426..477002910e 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -8,6 +8,9 @@ USAGE='[-n] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commi
. git-sh-setup
set_reflog_action "merge $*"
+test -z "$(git ls-files -u)" ||
+ die "You are in a middle of conflicted merge."
+
LF='
'