Junio C Hamano <junkio@xxxxxxx> writes:
> Jeff King <peff@xxxxxxxx> writes:
>
>> BTW, is there some explanation why branch.*.merge specifies a _remote_
>> head? The following would make much more sense to me:
>>
>> [branch "master"]
>> remote = origin
>> merge = refs/remotes/origin/master
>
> Only *if* you store it in that tracking branch. The name the
> other party gives _do_ matter to you anyway, because you have to
> _know_ it to fetch. What it does NOT matter is if you use a
> tracking branch, or if you do, which local tracking branch you
> use to track it.
Having said that, I think we _could_ do this.
If you (or other people) use branch.*.merge, with its value set
to remote name _and_ local name, and actually verify that either
form works without confusion, please report back and I'll apply.
My scar is still fresh from the "not having branch.*.merge is an
error" mistake, where the thing stayed on 'next' for the better
part of last week without anybody complaining, and immediately
broken peoples' workflows when it was pushed out to 'master'.
I really do not want to repeat that.
-- >8 --
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index aaef861..b45af5c 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -146,8 +146,13 @@ canon_refs_list_for_fetch () {
else
for merge_branch in $merge_branches
do
- [ "$remote" = "$merge_branch" ] &&
- dot_prefix= && break
+ if test "$remote" = "$merge_branch" ||
+ test "z$local" != z &&
+ test "$local" = "$merge_branch"
+ then
+ dot_prefix=
+ break
+ fi
done
fi
case "$remote" in
-
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