summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2006-12-22 23:25:21 (GMT)
committerJunio C Hamano <junkio@cox.net>2006-12-22 23:25:21 (GMT)
commitfb8696d9d82e78fe829fdd95ff9ff10fdfa52ef9 (patch)
tree1e473b4242ee0ecb31beddd1e5dc80e8b10f5047
parent228e2eb67e9f15983519f472cc1566a3dd857f9c (diff)
downloadgit-fb8696d9d82e78fe829fdd95ff9ff10fdfa52ef9.zip
git-fb8696d9d82e78fe829fdd95ff9ff10fdfa52ef9.tar.gz
git-fb8696d9d82e78fe829fdd95ff9ff10fdfa52ef9.tar.bz2
default pull: forget about "newbie protection" for now.
This will not be backward compatible no matter how you cut it. Shelve it for now until somebody comes up with a better way to determine when we can safely refuse to use the first set of branchse for merging without upsetting valid workflows. Signed-off-by: Junio C Hamano <junkio@cox.net>
-rwxr-xr-xgit-parse-remote.sh7
1 files changed, 0 insertions, 7 deletions
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index f163821..b163d22 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -145,13 +145,6 @@ canon_refs_list_for_fetch () {
merge_branches=$(git-repo-config \
--get-all "branch.${curr_branch}.merge")
fi
- # If we are fetching only one branch, then first branch
- # is the only thing that makes sense to merge anyway,
- # so there is no point refusing that traditional rule.
- if test $# != 1 && test "z$merge_branches" = z
- then
- merge_branches=..this..would..never..match..
- fi
fi
for ref
do