Git development
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@osdl.org>
Cc: Junio C Hamano <junkio@cox.net>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	git@vger.kernel.org
Subject: Re: [RFC][PATCH] Allow transfer of any valid sha1
Date: Thu, 25 May 2006 14:30:58 -0600	[thread overview]
Message-ID: <m13bexetj1.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0605251134410.5623@g5.osdl.org> (Linus Torvalds's message of "Thu, 25 May 2006 11:36:16 -0700 (PDT)")

Linus Torvalds <torvalds@osdl.org> writes:

> On Thu, 25 May 2006, Junio C Hamano wrote:
>> 
>> With the limitation of the current tool, we could do:
>> 
>>   git-fetch master.kernel.org:/pub/scm/.../torvalds/linux-2.6.git \
>> 	refs/heads/master:refs/remotes/linus/master
>>   git merge 'whatever merge message' HEAD b307e854
>> 
>> assuming that b307e854 is reachable from your tip.  So it might
>> be just a matter of giving a convenient shorthand to do the
>> above two commands, instead of mucking with upload-pack.
>
> It's not upload-pack that needs mucking with. It's simply "fetch-pack" 
> that currently will refuse to say "want b307e854..", because the only 
> thing it can do is say "want <headref>".
>
> So the patch would literally be to have a way to tell fetch-pack directly 
> what you want, and not have the "only select from remote branches" logic.

So fixing fetch-pack is easy and pretty non-controversial.
The patch below handles that.

The problem is that I then run into the limitations in upload-pack.

(The movement of filter_refs may actually be overkill)

Eric



diff --git a/fetch-pack.c b/fetch-pack.c
index a3bcad0..c767d84 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -260,6 +260,27 @@ static void mark_recent_complete_commits
 	}
 }
 
+static struct ref **get_sha1_heads(struct ref **refs, int nr_heads, char **head)
+{
+	int i;
+	for (i  = 0; i < nr_heads; i++) {
+		struct ref *ref;
+		unsigned char sha1[20];
+		char *s = head[i];
+		int len = strlen(s);
+
+		if (len != 40 || get_sha1_hex(s, sha1))
+			continue;
+
+		ref = xcalloc(1, sizeof(*ref) + len + 1);
+		memcpy(ref->old_sha1, sha1, 20);
+		memcpy(ref->name, s, len + 1);
+		*refs = ref;
+		refs = &ref->next;
+	}
+	return refs;
+}
+
 static void filter_refs(struct ref **refs, int nr_match, char **match)
 {
 	struct ref *prev, *current, *next;
@@ -311,6 +332,8 @@ static int everything_local(struct ref *
 	if (cutoff)
 		mark_recent_complete_commits(cutoff);
 
+	filter_refs(refs, nr_match, match);
+
 	/*
 	 * Mark all complete remote refs as common refs.
 	 * Don't mark them common yet; the server has to be told so first.
@@ -329,8 +352,6 @@ static int everything_local(struct ref *
 		}
 	}
 
-	filter_refs(refs, nr_match, match);
-
 	for (retval = 1, ref = *refs; ref ; ref = ref->next) {
 		const unsigned char *remote = ref->old_sha1;
 		unsigned char local[20];
@@ -373,6 +394,7 @@ static int fetch_pack(int fd[2], int nr_
 		packet_flush(fd[1]);
 		die("no matching remote head");
 	}
+	get_sha1_heads(&ref, nr_match, match);
 	if (everything_local(&ref, nr_match, match)) {
 		packet_flush(fd[1]);
 		goto all_done;
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 187f088..2372df8 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -105,6 +105,7 @@ canon_refs_list_for_fetch () {
 		'') remote=HEAD ;;
 		refs/heads/* | refs/tags/* | refs/remotes/*) ;;
 		heads/* | tags/* | remotes/* ) remote="refs/$remote" ;;
+		[0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]) ;;
 		*) remote="refs/heads/$remote" ;;
 		esac
 		case "$local" in

  reply	other threads:[~2006-05-25 20:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-24  7:51 [RFC][PATCH] Allow transfer of any valid sha1 Eric W. Biederman
2006-05-24  9:07 ` Junio C Hamano
2006-05-25  5:09   ` Eric W. Biederman
2006-05-25  6:36     ` Junio C Hamano
2006-05-25 17:00       ` Eric W. Biederman
2006-05-25 17:28         ` Linus Torvalds
2006-05-25 17:59           ` Eric W. Biederman
2006-05-25 18:28           ` Junio C Hamano
2006-05-25 18:36             ` Linus Torvalds
2006-05-25 20:30               ` Eric W. Biederman [this message]
2006-05-25 20:53                 ` Junio C Hamano
2006-05-26  8:27                   ` Eric W. Biederman
2006-05-26 10:04                 ` Junio C Hamano
2006-05-26 17:32                   ` Eric W. Biederman
2006-05-25 20:50             ` Eric W. Biederman
2006-05-25 21:04               ` Junio C Hamano
2006-05-26  8:32                 ` Eric W. Biederman
2006-06-08  9:33                 ` Eric W. Biederman

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=m13bexetj1.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=torvalds@osdl.org \
    /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