Revision e5dce96e9e26f8e30291c79fa5647313c64b2150 authored by Junio C Hamano on 21 September 2012, 19:09:42 UTC, committed by Junio C Hamano on 21 September 2012, 19:14:19 UTC
Make it clear to people who (rightly or wrongly) think that the "--follow" option should follow origin across while-file renames that we already do so. That would explain the output that they see when they do give the "--follow" option to the command. We may or may not want to do a "--no-follow" patch as a follow-up, but that is a separate topic. Signed-off-by: Junio C Hamano <gitster@pobox.com>
1 parent bafc478
git-merge-resolve.sh
#!/bin/sh
#
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2005 Junio C Hamano
#
# Resolve two trees, using enhanced multi-base read-tree.
# The first parameters up to -- are merge bases; the rest are heads.
bases= head= remotes= sep_seen=
for arg
do
case ",$sep_seen,$head,$arg," in
*,--,)
sep_seen=yes
;;
,yes,,*)
head=$arg
;;
,yes,*)
remotes="$remotes$arg "
;;
*)
bases="$bases$arg "
;;
esac
done
# Give up if we are given two or more remotes -- not handling octopus.
case "$remotes" in
?*' '?*)
exit 2 ;;
esac
# Give up if this is a baseless merge.
if test '' = "$bases"
then
exit 2
fi
git update-index -q --refresh
git read-tree -u -m --aggressive $bases $head $remotes || exit 2
echo "Trying simple merge."
if result_tree=$(git write-tree 2>/dev/null)
then
exit 0
else
echo "Simple merge failed, trying Automatic merge."
if git-merge-index -o git-merge-one-file -a
then
exit 0
else
exit 1
fi
fi
![swh spinner](/static/img/swh-spinner.gif)
Computing file changes ...