[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: send-pack question.
From:       Linus Torvalds <torvalds () osdl ! org>
Date:       2005-07-31 6:02:57
Message-ID: Pine.LNX.4.58.0507302257000.29650 () g5 ! osdl ! org
[Download RAW message or body]



On Sat, 30 Jul 2005, Junio C Hamano wrote:
> 
>  * Right now, "send-pack --all" into an empty repository does
>    not do anything, but "send-pack --all master" into an empty
>    repository pushes all local heads.  This is because we do not
>    check "send_all" when deciding if we want to call try_match
>    on local references.  I am assuming this is an oversight; am
>    I correct?  If so, does the attached patch look OK?

Yeah, that sounds like me just not having taken my 'meds. The patch looks 
fine.

>  * It appears to me that you can say "send-pack net", and
>    depending on how the remote lists its refs, you can end up
>    updating their refs/heads/net or refs/tags/net.

Yeh. I was wanting to sort the refs to make everything be totally 
repeatable, but that was more of an urge than a real plan.

>						  More
>    confusingly, you could say "send-pack net net" to update
>    both.  More realistically, you could get confused with a
>    remote that has refs/heads/jgarzik/net and
>    refs/heads/dsmiller/net in this way.  I think it should
>    detect, stop and warn about the ambiguity and require the
>    user to be more explicit.  Am I reading the current code
>    correctly?

Yes, warning on ambiguity sounds like a sound plan, and then you don't 
need to sort.

You also probably to come up with a syntax for saying "xyz is the local
name, abc is the remote name". That's needed for both the pulling and the 
pushing side, but I didn't ever do it. 

>    I've always _hated_ the interface to path_match() which
>    pretends to be just a boolean function but actually has a
>    grave side effect, by the way.

It's "interesting" but useful. But I agree, we've had one bug already due
to the interesting part.

If you do the ambiguity thing, you might mark them used some separate way, 
and maybe avoid that side effect (or rather - the side effect would still 
exist, but instead of removing the entry, it would just mark it as 
"seen", ie make it less drastic).

		Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]