Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> So, if I understand your option (2) correctly, it complains _only_ if
> there is at least one branch.*.merge in the config, but not for the
> current branch?
>
> I think that would safeguard the existing repositories _and_ the new ones,
> because git-clone sets them up with such an entry to begin with.
>
> If that behaviour was meant by (2), I am all for it.
I am not quite sure about that. An old timer would work in a
newly cloned repository after all, and what this "newbie
protection" is breaking is not existing repositories but
expectation from existing users.
In any case, here is a patch for discussion.
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index f163821..b4d071b 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -145,10 +145,22 @@ 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
+ if test "z$merge_branches" = z &&
+ # 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.
+ test $# != 1 &&
+
+ # Also, old timers have been happily working
+ # with the first branch rule without having
+ # any branch.*.merge configuration, so if
+ # there is none, do not bother with this
+ # "newbie protection". A newly cloned
+ # repository would have branch.master.merge
+ # set for it.
+ git repo-config --get-regexp \
+ '^branch\..*\.merge$' >/dev/null
then
merge_branches=..this..would..never..match..
fi
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html