Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories

From: Junio C Hamano <junkio@cox.net>
Date: Nov 4, 2005, 21:50 UTC
Message-ID: <7voe50rskh.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20051104210820.GM1431@pasky.or.cz>

Petr Baudis <pasky@suse.cz> writes:

> I still believe we need the notion of private tags which shouldn't be
> cloned.

I agree with you violently. I just do not know what is the right convention to tell which is private and which is not.

Fetching used to be a different matter, because we did not do 'git-fetch --tags' for a reason: you do not have any business with my tags unless I tell you about them. But now we tell others about what tags we have, so...

> All right. git-update-server-info ignores hidden refs, but referencing a
> hidden ref works all right (unsurprisingly). So let's just codify that
> private tags which shan't be fetched (unless requested explicitly) start
> with a dot (/^\./) and we are all set...?

Except that I suspect refs.c::check_ref_format() will barf on it instead of ignoring it, and obviously you would want it to do two different things depending on what kind of operation you are doing. You for example would want to change git-branch or git-tag not to refuse creating such "private" tag. You would still want git-upload-pack to show it to the other end, for better common commit computation purposes, especially if the tag is of lightweight kind, but would want git-clone to ignore them. It should be doable but we first need a plan.