From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Tree tags again..
Date: Thu, 04 Aug 2005 17:17:55 -0700 [thread overview]
Message-ID: <7vu0i5qlsc.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0508041702180.3258@g5.osdl.org> (Linus Torvalds's message of "Thu, 4 Aug 2005 17:03:17 -0700 (PDT)")
Linus Torvalds <torvalds@osdl.org> writes:
> Junio, maybe there should be some test-case for this:
>
> error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
> error: remote ref 'refs/tags/v2.6.11' is not a strict subset of local ref 'refs/tags/v2.6.11'.
I assume this is syncing two linux-2.6 repo which both have the
same refs/tags/v2.6.11 (tree tag).
Sorry, in send_pack(), up-to-date check should be made first
before ref_newer() check. My mistake.
A more interesting question is what to do if they are indeed
different trees. More realistically, you may decide to
retroactively create a commit that wraps the same v2.6.11 tree,
perhaps grafting it in front of the current 2.6.12-rcX based
history, and replace 'refs/tags/v2.6.11' with a tag to that
commit. What should happen?
I do not have a good answer to that. From the end-user point of
view, we _could_ treat tags differently from heads in that we
always omit the ref_newer() check, but from the machinery point
of view, I think the plumbing should just ask the user to use
the --force when such a tag is involved.
------------
diff --git a/send-pack.c b/send-pack.c
--- a/send-pack.c
+++ b/send-pack.c
@@ -173,6 +173,10 @@ static int send_pack(int in, int out, in
char old_hex[60], *new_hex;
if (!ref->peer_ref)
continue;
+ if (!memcmp(ref->old_sha1, ref->peer_ref->new_sha1, 20)) {
+ fprintf(stderr, "'%s': up-to-date\n", ref->name);
+ continue;
+ }
if (!is_zero_sha1(ref->old_sha1)) {
if (!has_sha1_file(ref->old_sha1)) {
error("remote '%s' object %s does not "
@@ -188,10 +192,6 @@ static int send_pack(int in, int out, in
continue;
}
}
- if (!memcmp(ref->old_sha1, ref->peer_ref->new_sha1, 20)) {
- fprintf(stderr, "'%s': up-to-date\n", ref->name);
- continue;
- }
memcpy(ref->new_sha1, ref->peer_ref->new_sha1, 20);
if (is_zero_sha1(ref->new_sha1)) {
error("cannot happen anymore");
next prev parent reply other threads:[~2005-08-05 0:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-05 0:03 Tree tags again Linus Torvalds
2005-08-05 0:17 ` Junio C Hamano [this message]
2005-08-05 9:16 ` Junio C Hamano
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=7vu0i5qlsc.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).