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".
> 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
> will become ambiguous if you allowed ".share" as a refname
> shorthand. It could mean either one of these:
> 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