Re: [PATCH] [SIGNED-OFF] remotes-hg: bugfix for fetching non local remotes

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 24, 2013, 15:20 UTC
Message-ID: <7v7ggg6l2o.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CALWbr2wDqo29kRJ2eHsozRCN_fT3tumYz23pQa5P-9dm27OL6A@mail.gmail.com>

Antoine Pelisse <apelisse@gmail.com> writes:

Show 10 quoted lines

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