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: 
hg/<remote_name>/{branches,bookmarks}/{master,default,…}.
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 ;)

Cheers,
Jörn

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