All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Jay Soffian <jaysoffian@gmail.com>,
	git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>
Subject: Re: [PATCH] builtin-remote: better handling of multiple remote HEADs
Date: Sat, 14 Feb 2009 16:15:48 -0500	[thread overview]
Message-ID: <20090214211548.GA14898@coredump.intra.peff.net> (raw)
In-Reply-To: <alpine.LNX.1.00.0902141503230.19665@iabervon.org>

On Sat, Feb 14, 2009 at 03:21:30PM -0500, Daniel Barkalow wrote:

> I haven't checked lately, but I think that what's actually needed is to 
> have the locate_head() function notice if the struct ref for HEAD actually 
> has the symref field non-NULL, and report that as the unambiguous answer. 

Indeed. Something like the patch below works (on top of Jay's patches).
But it has two shortcomings:

  1. There is no test script, since we have no infrastructure for
     testing over http. I might be able to build something on top of
     what's in the http-push tests.

     I was hoping we could do the same trick for local file repos, which
     would be easy to test. But the transport code just treats them as
     regular pack uploaders; only some specialized code in clone cares
     about the difference.

     In theory we could add a new transport for local repos. I don't
     think it would make sense for its get_remote_refs function to get
     _all_ of the refs, but it could specially peek at HEAD and set the
     symref field appropriately.

  2. The guess_remote_head function is getting a little long. I think it
     would help to refactor it into two functions; one for finding the
     remote HEAD in the refs list, and the other for guessing at a ref
     which matches the HEAD.

I will try to make something a little neater later today.

> This should also allow it to automatically pick up any other 
> disambiguation by future sources of lists of refs that include HEAD, 
> whether that's git protocol extensions, filesystem access to the repo, or 
> foreign VCSes where some branches is inherently primary, or whatever.

Yes, I think the symref field for the ref is a very sensible way of
communicating the information for that reason.

Patch is below.

---
diff --git a/remote.c b/remote.c
index 6385a22..afbaccc 100644
--- a/remote.c
+++ b/remote.c
@@ -1404,6 +1404,20 @@ const struct ref *guess_remote_head(const struct ref *refs,
 	if (!remote_head)
 		return NULL;
 
+	/* if the underlying transport can represent symrefs,
+	 * then we don't need to guess at all */
+	if (remote_head->symref) {
+		for (r = mapped_refs; r; r = r->next) {
+			if (!strcmp(r->name, remote_head->symref)) {
+				if (all_matches_p) {
+					*all_matches_p = copy_ref(r);
+					(*all_matches_p)->peer_ref = NULL;
+				}
+				return r;
+			}
+		}
+	}
+
 	/* If refs/heads/master could be right, it is. */
 	if (remote_master && !hashcmp(remote_master->old_sha1,
 				      remote_head->old_sha1))

  reply	other threads:[~2009-02-14 21:18 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-13  8:54 [PATCH 0/4] remote HEAD improvements take 2 Jay Soffian
2009-02-13  8:54 ` [PATCH 1/4] builtin-clone: move locate_head() to remote.c so it can be re-used Jay Soffian
2009-02-13  8:54   ` [PATCH 2/4] builtin-remote: move duplicated cleanup code its own function Jay Soffian
2009-02-13  8:54     ` [PATCH 3/4] builtin-remote: teach show to display remote HEAD Jay Soffian
2009-02-13  8:54       ` [PATCH 4/4] builtin-remote: add set-head verb Jay Soffian
2009-02-13 10:09         ` Junio C Hamano
2009-02-13 10:21           ` Jay Soffian
2009-02-13 11:42             ` [PATCH v2 4/4] builtin-remote: add set-head subcommand Jay Soffian
2009-02-13 10:35           ` [PATCH 4/4] builtin-remote: add set-head verb Junio C Hamano
2009-02-13 10:52             ` Jay Soffian
2009-02-14  0:22           ` Jeff King
2009-02-14  2:00             ` Junio C Hamano
2009-02-14  2:18               ` Jeff King
2009-02-14  2:48                 ` Jay Soffian
2009-02-14  2:59               ` Jay Soffian
2009-02-14  3:43                 ` Jeff King
2009-02-14 10:30                   ` [PATCH] builtin-remote: better handling of multiple remote HEADs Jay Soffian
2009-02-14 17:54                     ` Jeff King
2009-02-14 18:35                       ` Jay Soffian
2009-02-14 18:54                         ` Jeff King
2009-02-14 19:48                           ` Junio C Hamano
2009-02-14 20:21                       ` Daniel Barkalow
2009-02-14 21:15                         ` Jeff King [this message]
2009-02-15  6:08                           ` Jeff King
2009-02-15  6:10                             ` [PATCH 1/5] test scripts: refactor start_httpd helper Jeff King
2009-02-15  6:12                             ` [PATCH 2/5] add basic http clone/fetch tests Jeff King
2009-02-15  8:01                               ` Junio C Hamano
2009-02-15  6:12                             ` [PATCH 3/5] refactor find_refs_by_name to accept const list Jeff King
2009-02-15  6:16                             ` [PATCH 4/5] remote: refactor guess_remote_head Jeff King
2009-02-15  6:18                             ` [PATCH 5/5] remote: use exact HEAD lookup if it is available Jeff King
2009-02-15 15:22                               ` Jay Soffian
2009-02-15 19:58                               ` Jeff King
2009-02-15 20:00                                 ` [PATCH 1/2] transport: cleanup duplicated ref fetching code Jeff King
2009-02-15 20:01                                 ` [PATCH 2/2] transport: unambiguously determine local HEAD Jeff King
2009-02-15  5:27                     ` [PATCH] builtin-remote: better handling of multiple remote HEADs Jeff King
2009-02-15  5:34                       ` Jeff King
2009-02-15 14:13                       ` Jay Soffian
2009-02-15 15:12                         ` Jeff King
2009-02-16  2:21                         ` Junio C Hamano
2009-02-16  2:58                           ` Jay Soffian
2009-02-13  8:57 ` [PATCH 0/4] remote HEAD improvements take 2 Jay Soffian

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=20090214211548.GA14898@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jaysoffian@gmail.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.