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
next prev parent 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