From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 24 Jul 2013 15:20:47 GMT
Subject: Re: [PATCH] [SIGNED-OFF] remotes-hg: bugfix for fetching non local remotes
Message-ID: <7v7ggg6l2o.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALWbr2wDqo29kRJ2eHsozRCN_fT3tumYz23pQa5P-9dm27OL6A@mail.gmail.com>

Antoine Pelisse <apelisse@gmail.com> writes:

> On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees <dev@joernhees.de> wrote:
>> On 24.07.2013, at 10:52, Antoine Pelisse <apelisse@gmail.com> wrote:
>>> I think the best way would be to create the shared repository in
>>> .git/hg/$share, with $share being a path that can't be a remote name
>>> (so that it doesn't conflict with remote directories),
>>
>> Maybe ".git/hg/.share"?
>
> According to Documentation/git-check-ref-format.txt, I'm not sure if
> we should start with a dot, or end with it.

What are in these directories under .git/hg?  Surely they cannot be
refs in Git's sense, as that hierarchy is not known to anything and
will not be protected from "git gc".

Puzzled...

	Goes and looks...

OK, the tracking branches for these are created under refs/hg/*
using the same name.

A refname shouldn't begin or end with a dot, because the range

	master...share

will become ambiguous if you allowed ".share" as a refname
shorthand.  It could mean either one of these:

	master..refs/heads/.share
        master...refs/heads/share

The same for the trailing dot "share."; the range "share...master"
becomes ambiguous.