diff options
| author | Junio C Hamano <junkio@cox.net> | 2006-12-22 15:25:21 -0800 |
|---|---|---|
| committer | Junio C Hamano <junkio@cox.net> | 2006-12-22 15:25:21 -0800 |
| commit | fb8696d9d82e78fe829fdd95ff9ff10fdfa52ef9 (patch) | |
| tree | 1e473b4242ee0ecb31beddd1e5dc80e8b10f5047 | |
| parent | 228e2eb67e9f15983519f472cc1566a3dd857f9c (diff) | |
| download | git-fb8696d9d82e78fe829fdd95ff9ff10fdfa52ef9.tar.gz | |
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-x | git-parse-remote.sh | 7 |
1 files changed, 0 insertions, 7 deletions
diff --git a/git-parse-remote.sh b/git-parse-remote.sh index f163821d03..b163d22ddb 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 |