git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Cc: "Shawn O . Pearce" <spearce@spearce.org>,
	Jay Soffian <jaysoffian@gmail.com>,
	Stefan Zager <szager@google.com>
Subject: [RFC/PATCH] ignoring a fetch that overwrites local symref
Date: Tue, 11 Dec 2012 11:46:45 -0800	[thread overview]
Message-ID: <7v62488j8a.fsf_-_@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1271714912-56659-1-git-send-email-jaysoffian@gmail.com> (Jay Soffian's message of "Mon, 19 Apr 2010 18:08:29 -0400")

This is a companion to an ancient thread

    http://thread.gmane.org/gmane.comp.version-control.git/145311/focus=145337

in which an error was dealt with while pushing into a "mirror"
repository that has a symbolic reference refs/remotes/origin/HEAD
pointing at refs/remotes/origin/master with "git push --mirror".
The issue was that the receiving end was told to update origin/HEAD
and origin/master separately; if origin/HEAD is updated, that would
update origin/master at the same time, and then when attempting to
update origin/master, it would notice that it no longer has the
expected old value and barf.  After the series, we started ignoring
such pushes to HEAD on the receiving end.

But you can suffer from a similar issue transferring objects in the
opposite direction.  If you run "fetch --mirror" in to such a
"mirror" repository, the other side would advertise both 'master'
and 'HEAD' under refs/remotes/origin/ hierarchy, and refs/*:refs/*
wildcard would try to grab both of them.

Work it around by noticing a wildcard match that attempts to update
a local symbolic ref and ignoring it.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * While I do not think it is sane to have symbolic refs in the
   receiving ref hierarchy (e.g. refs/remotes/origin/) that has a
   matching ref in the corresponding ref hierarchy in the sending
   side (e.g. the same, or refs/heads/ if you are doing a mirror) in
   the first place, we addressed the issue brought by such a setting
   on the push side, so it is probably a good idea to do it on the
   fetch side.

   This is marked RFC as it cheats by ignoring symrefs that were not
   explicitly asked, instead of doing the "is the underlying thing
   going to be updated with the same operation?" logic the old patch
   did in da3efdb (receive-pack: detect aliased updates which can
   occur with symrefs, 2010-04-19). I think this simpler logic is
   sufficient but there may be corner cases that merit the more
   elaborate one, hence RFC.

 remote.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git i/remote.c w/remote.c
index 6aa49c0..ca1f8f2 100644
--- i/remote.c
+++ w/remote.c
@@ -1370,6 +1370,16 @@ int branch_merge_matches(struct branch *branch,
 	return refname_match(branch->merge[i]->src, refname, ref_fetch_rules);
 }
 
+static int ignore_symref_update(const char *refname)
+{
+	unsigned char sha1[20];
+	int flag;
+
+	if (!resolve_ref_unsafe(refname, sha1, 0, &flag))
+		return 0; /* non-existing refs are OK */
+	return (flag & REF_ISSYMREF);
+}
+
 static struct ref *get_expanded_map(const struct ref *remote_refs,
 				    const struct refspec *refspec)
 {
@@ -1383,7 +1393,8 @@ static struct ref *get_expanded_map(const struct ref *remote_refs,
 		if (strchr(ref->name, '^'))
 			continue; /* a dereference item */
 		if (match_name_with_pattern(refspec->src, ref->name,
-					    refspec->dst, &expn_name)) {
+					    refspec->dst, &expn_name) &&
+		    !ignore_symref_update(expn_name)) {
 			struct ref *cpy = copy_ref(ref);
 
 			cpy->peer_ref = alloc_ref(expn_name);

  reply	other threads:[~2012-12-11 19:47 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-19 16:25 [PATCH v2 1/2] receive-pack: switch global variable 'commands' to a parameter Jay Soffian
2010-04-19 16:25 ` [PATCH v2 2/2] receive-pack: detect aliased updates which can occur with symrefs Jay Soffian
2010-04-19 16:31   ` Jay Soffian
2010-04-19 16:39   ` Jay Soffian
2010-04-19 20:39     ` Junio C Hamano
2010-04-19 20:57       ` Jay Soffian
2010-04-19 22:08   ` [PATCH v3 0/3] js/maint-receive-pack-symref-alias Jay Soffian
2012-12-11 19:46     ` Junio C Hamano [this message]
2012-12-11 22:32       ` [PATCH] fetch: ignore wildcarded refspecs that update local symbolic refs Junio C Hamano
2012-12-12 17:17         ` Jay Soffian
2012-12-12 19:13       ` [RFC/PATCH] ignoring a fetch that overwrites local symref Shawn Pearce
2012-12-12 19:38         ` Junio C Hamano
2010-04-19 22:08   ` [PATCH v3 1/3] receive-pack: switch global variable 'commands' to a parameter Jay Soffian
2010-04-19 22:08   ` [PATCH v3 2/3] t5516-fetch-push.sh: style cleanup Jay Soffian
2010-04-19 22:08   ` [PATCH v3 3/3] receive-pack: detect aliased updates which can occur with symrefs Jay Soffian
2010-04-19 22:19   ` Jay Soffian
2010-06-10 18:06     ` Ævar Arnfjörð Bjarmason

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v62488j8a.fsf_-_@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jaysoffian@gmail.com \
    --cc=spearce@spearce.org \
    --cc=szager@google.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).