On 24 Jul 2013, at 17:20, Junio C Hamano <gits...@pobox.com> wrote:

> Antoine Pelisse <apeli...@gmail.com> writes:
>> On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees <d...@joernhees.de> wrote:
>>> On 24.07.2013, at 10:52, Antoine Pelisse <apeli...@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.

I think there is a slight misunderstanding here:
.git/hg/<remote_name> will be the actual directory for a hg:: remote, which 
will then use mercurial internal magic to refer to the shared repo 
.git/hg/.shared in case the remote is not somewhere on the local filesystem, 
otherwise that path is used.

What will appear in the refs is something like: 
So the .shared will correctly never appear in a git ref, which is what we want. 
It can also not clash with a remote as ".shared" is not a valid name… also what 
we want ;)


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to