On 24 Jul 2013, at 17:20, Junio C Hamano <[email protected]> wrote:
> Antoine Pelisse <[email protected]> writes:
>
>> On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees <[email protected]> wrote:
>>> On 24.07.2013, at 10:52, Antoine Pelisse <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
