This does two things:
- It changes the hardcoded default merge strategy for two-head
git-pull from resolve to recursive.
- .git/config file acquires two configuration items.
pull.twohead names the strategy for two-head case, and
pull.octopus names the strategy for octopus merge.
IOW you are paranoid, you can have the following lines in your
.git/config file and keep using git-merge-resolve when pulling
one remote:
[pull]
twohead = resolve
OTOH, you can say this:
[pull]
twohead = resolve
twohead = recursive
to try quicker resolve first, and when it fails, fall back to
recursive.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Linus Torvalds <torvalds@osdl.org> writes:
> Hmm. True. The _really_ trivial in-index case triggers for me pretty
> often, but I haven't done any statistics. It might be only 50% of the
> time.
>...
> It's certainly an option to just do what I just did, namely use the
> default one until it breaks, and then just do "git reset --hard" and re-do
> the pull with "-s recursive". A bit sad, and it would be good to have
> coverage on the recursive strategy..
Hopefully something like this would make people aware of
recursive and give it a wider coverage and chance to mature.
git-pull.sh | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
applies-to: 75922cf23cc070e2d5220d961a8f645f1bc8bb60
3acc20beaf0df9ce11a1b7aabf8c9dc7507a9b44
diff --git a/git-pull.sh b/git-pull.sh
index 2358af6..3b875ad 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -79,10 +79,22 @@ case "$merge_head" in
exit 0
;;
?*' '?*)
- strategy_default_args='-s octopus'
+ var=`git-var -l | sed -ne 's/^pull\.octopus=/-s /p'`
+ if test '' = "$var"
+ then
+ strategy_default_args='-s octopus'
+ else
+ strategy_default_args=$var
+ fi
;;
*)
- strategy_default_args='-s resolve'
+ var=`git-var -l | sed -ne 's/^pull\.twohead=/-s /p'`
+ if test '' = "$var"
+ then
+ strategy_default_args='-s recursive'
+ else
+ strategy_default_args=$var
+ fi
;;
esac
---
0.99.9.GIT
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
