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

From: Petr Baudis <pasky@suse.cz>
Date: Nov 4, 2005, 21:08 UTC
Message-ID: <20051104210820.GM1431@pasky.or.cz>
In-Reply-To: <7vvez8wbpz.fsf@assigned-by-dhcp.cox.net>

Dear diary, on Fri, Nov 04, 2005 at 06:43:04PM CET, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Show 5 quoted lines

>   I once considered to give an option to clone to map the origin
>   heads to .git/refs/heads/origin/{master,maint,pu,...}.  In
>   hindsight that might have been cleaner.  Instead I just followed
>   what Cogito already established, and mapped remote "master" to
>   "origin".

Well, that obviously works only when you resign on the workflow where pull means fetch + merge, since your local master would conflict with the remote master, therefore having nowhere to store the remote master.

Show 7 quoted lines

> . The namespace under refs/tags theoretically also has the same
>   issue, but I suspect it would not matter too much in practice.
>   The tags people fetches from remote tend to be release-point
>   tags (e.g. v2.6.14) whose names implicitly follow an obvious
>   (to humans) naming convention; when you name your temporary
>   anchor points using lightweight tags, you can easily avoid
>   name clashes with those "for other people" tags [*2*].

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

Hmm. Wait.

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

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.