On Thu, Apr 05, 2007 at 02:18:58PM -0700, Junio C Hamano wrote:
> IIRC "git push" without explicit refspecs push the matching
> refs, but I am a bit under the weather and feverish, so don't
> take my word literally but look at git-push manual page please.
Ah, yes you're right. It really doesn't make sense to push
refs/remotes/* in most cases, since they're just tracking branches, and
if the destination _does_ have them, then it is unlikely to be in sync
with you (leading to Bill's problem). OTOH, you might want to be able
to push them explicitly if you are doing a strict mirror of a
repository.
The patch below turns off refs/remotes/ sending for "git-push" and
"git-push --all", but still allows "git-push origin
remotes/origin/master". I'm not sure about the semantics; maybe --all
should imply even remotes?
It also only impacts send-pack; I suspect pushing over dumb transports
now has different behavior, but I haven't looked. My testing was light,
so I may have totally broken something else, too. Input from more
clueful people would be helpful.
Does this seem like a sane direction to take? It just seems silly to be
pushing refs/remotes, which 99% of the time should be a purely local
thing.
-Peff
---
diff --git a/send-pack.c b/send-pack.c
index d5b5162..39829e3 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -131,6 +131,8 @@ static int one_local_ref(const char *refname, const unsigned char *sha1, int fla
{
struct ref *ref;
int len = strlen(refname) + 1;
+ if (!prefixcmp(refname, "refs/remotes/"))
+ return 0;
ref = xcalloc(1, sizeof(*ref) + len);
hashcpy(ref->new_sha1, sha1);
memcpy(ref->name, refname, len);
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html