From: Junio C Hamano <junkio@cox.net>
To: Petr Baudis <pasky@suse.cz>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Make git-clone --use-separate-remote the default
Date: Thu, 23 Nov 2006 22:36:49 -0800 [thread overview]
Message-ID: <7vpsbde4fy.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <7vzmahe6qe.fsf@assigned-by-dhcp.cox.net> (Junio C. Hamano's message of "Thu, 23 Nov 2006 21:47:21 -0800")
Junio C Hamano <junkio@cox.net> writes:
> However, this simple command fails:
>
> $ git push $URL master
>
> if the target repository $URL is made with use-separate-remote.
>
> This is because 'master' matches more than one on the remote
> side (heads/master and remotes/origin/master) which triggers
> "Hey, that's ambiguous, make yourself clear which one you mean!"
> check. This breaks t5400 test. We could "fix" the test to make
> it more explicit, but that is just a workaround.
>
> I think the send-pack/receive-pack pair needs to be taught that
> an unadorned branch name 'master' never matches anything under
> refs/remotes. This means that it would require an explicit
> refspec heads/master:remotes/origin/master in order to pudate
> refs under refs/remotes on the remote side with a push.
> ...
> The function to fix is connect.c::match_explicit_refs() and I
> _think_ making connect.c::count_refspec_match() not to consider
> 'foo' to match 'refs/remotes/origin/foo' (but still keeping it
> to match 'refs/heads/foo' or 'refs/tags/foo') is enough to make
> this happen.
That is,...
-- >8 --
[PATCH] refs outside refs/{heads,tags} match less strongly.
This changes the refname matching logic used to decide which ref
is updated with git-send-pack. We used to error out when
pushing 'master' when the other end has both 'master' branch and
a tracking branch 'remotes/$name/master' but with this, 'master'
matches only 'refs/heads/master' when both and no other 'master'
exist.
Pushing 'foo' when both heads/foo and tags/foo exist at the
remote end is still considered an error and you would need to
disambiguate between them by being more explicit.
When neither heads/foo nor tags/foo exists at the remote,
pushing 'foo' when there is only remotes/origin/foo is not
ambiguous, while it still is ambiguous when there are more than
one such weaker match (remotes/origin/foo and remotes/alt/foo,
for example).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/connect.c b/connect.c
index c55a20a..b9666cc 100644
--- a/connect.c
+++ b/connect.c
@@ -174,21 +174,58 @@ static int count_refspec_match(const cha
struct ref *refs,
struct ref **matched_ref)
{
- int match;
int patlen = strlen(pattern);
+ struct ref *matched_weak = NULL;
+ struct ref *matched = NULL;
+ int weak_match = 0;
+ int match = 0;
- for (match = 0; refs; refs = refs->next) {
+ for (weak_match = match = 0; refs; refs = refs->next) {
char *name = refs->name;
int namelen = strlen(name);
+ int weak_match;
+
if (namelen < patlen ||
memcmp(name + namelen - patlen, pattern, patlen))
continue;
if (namelen != patlen && name[namelen - patlen - 1] != '/')
continue;
- match++;
- *matched_ref = refs;
+
+ /* A match is "weak" if it is with refs outside
+ * heads or tags, and did not specify the pattern
+ * in full (e.g. "refs/remotes/origin/master") or at
+ * least from the toplevel (e.g. "remotes/origin/master");
+ * otherwise "git push $URL master" would result in
+ * ambiguity between remotes/origin/master and heads/master
+ * at the remote site.
+ */
+ if (namelen != patlen &&
+ patlen != namelen - 5 &&
+ strncmp(name, "refs/heads/", 11) &&
+ strncmp(name, "refs/tags/", 10)) {
+ /* We want to catch the case where only weak
+ * matches are found and there are multiple
+ * matches, and where more than one strong
+ * matches are found, as ambiguous. One
+ * strong match with zero or more weak matches
+ * are acceptable as a unique match.
+ */
+ matched_weak = refs;
+ weak_match++;
+ }
+ else {
+ matched = refs;
+ match++;
+ }
+ }
+ if (!matched) {
+ *matched_ref = matched_weak;
+ return weak_match;
+ }
+ else {
+ *matched_ref = matched;
+ return match;
}
- return match;
}
static void link_dst_tail(struct ref *ref, struct ref ***tail)
next prev parent reply other threads:[~2006-11-24 6:36 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-23 22:58 [PATCH] Make git-clone --use-separate-remote the default Petr Baudis
2006-11-23 23:12 ` Junio C Hamano
2006-11-23 23:39 ` Andy Whitcroft
2006-11-23 23:42 ` Petr Baudis
2006-11-23 23:45 ` J. Bruce Fields
2006-11-24 0:17 ` Junio C Hamano
2006-11-24 5:47 ` Junio C Hamano
2006-11-24 6:36 ` Junio C Hamano [this message]
2006-11-24 10:14 ` Salikh Zakirov
2006-11-24 11:24 ` Junio C Hamano
2006-11-24 11:56 ` Salikh Zakirov
2006-11-24 23:28 ` Salikh Zakirov
2006-11-25 0:04 ` Junio C Hamano
2006-11-24 11:32 ` Sergey Vlasov
2006-11-24 11:37 ` Junio C Hamano
2006-11-24 9:22 ` Jakub Narebski
2006-11-24 9:58 ` Salikh Zakirov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vpsbde4fy.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=pasky@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).