From: Petr Baudis Date: Fri, 04 Nov 2005 21:08:20 GMT Subject: Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories 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 told me that... > 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. > . 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.