Re: send-pack question.

From: Linus Torvalds <torvalds@osdl.org>
Date: Jul 31, 2005, 06:02 UTC
Message-ID: <Pine.LNX.4.58.0507302257000.29650@g5.osdl.org>
In-Reply-To: <7v1x5fwmpk.fsf@assigned-by-dhcp.cox.net>

On Sat, 30 Jul 2005, Junio C Hamano wrote:

Show 7 quoted lines

> 
>  * 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.

Show 8 quoted lines

>						  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