Re: [PATCH] [SIGNED-OFF] remotes-hg: bugfix for fetching non local remotes
- From
Jörn Hees <dev@joernhees.de>
- Date
- Jul 24, 2013, 15:28 UTC
- Message-ID
- <665576E7-6083-4535-9CE0-773236A0E9ED@joernhees.de>
- In-Reply-To
- <7v7ggg6l2o.fsf@alter.siamese.dyndns.org>
On 24 Jul 2013, at 17:20, Junio C Hamano <gitster@pobox.com> wrote:
Show 36 quoted lines
> Antoine Pelisse <apelisse@gmail.com> writes: > >> 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.
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