git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] [SIGNED-OFF] remotes-hg: bugfix for fetching non local remotes

From
Antoine Pelisse <apelisse@gmail.com>
Date
Jul 24, 2013, 13:14 UTC
Message-ID
<CALWbr2wDqo29kRJ2eHsozRCN_fT3tumYz23pQa5P-9dm27OL6A@mail.gmail.com>
In-Reply-To
<F0461ED2-7B5F-4657-B0D4-3CBBE15FDD48@joernhees.de>
On Wed, Jul 24, 2013 at 11:59 AM, Jörn Hees <dev@joernhees.de> wrote:
Show 6 quoted lines
> 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.

Show 5 quoted lines
>> That way, the share can be created even if .git/hg already exists
>> (because of a previous import, before the shared machinery existed, or
>> because you already have a local remote).
>
> I like the idea of having independent remotes (fetching one, doesn't update another). http://mercurial.selenic.com/wiki/ShareExtension warns about this, and i wasn't sure it wouldn't cause intricate bugs. > This is why I opted for the explicit cloning, no shared history for several remotes.

I think the goal of using sharing here is that Mercurial and Git may use different schemes to handle branches. Mercurial may lead you to have separate repositories for each branch (They seem to do it for its own development [1]). All these branches actually share most of the same history, and are fully related, and we usually handle this situation in Git with one repository with multiple branches. Using "hg share", we allow a smooth transition from Mercurial model to Git model by merging all Mercurial repositories into one, and then map this single repository to the Git repository. IOW, the goal is to have only one copy of each "hg object" that are shared amongst many "remotes" (and potentially import them only once, though I don't think it currently works for me).

Show 8 quoted lines
>>> Changing gitdir to dirname causes shared_path ==
>>> .git/hg/<remote_name>/hg. The call to hg.share with local_path ==
>>> .git/hg/<remote_name>/clone works again.
>>
>> I think that will be a problem, because then the shared_path will no
>> longer be shared, will it ?
>
> Yupp, the shared_paths won't be shared, so it's not as optimal as possible, but it will work at least ;)

If we decided to remove the sharing idea, I think we should revert Felipe's commit rather than leave the shared_path variable, and call hg.share() on repository we don't even mean to share. That would be very confusing.

[1]: http://mercurial.selenic.com/wiki/DeveloperRepos
Previous: Jörn HeesNext: Jörn Hees
Message 4 of 9 in “[SIGNED-OFF] remotes-hg: bugfix for fetching non local remotes”
  1. [SIGNED-OFF] remotes-hg: bugfix for fetching non local remotesJoern Hees, Jul 23, 2013
  2. Antoine PelisseJul 24, 2013
  3. Jörn HeesJul 24, 2013
  4. Antoine PelisseJul 24, 2013
  5. Jörn HeesJul 24, 2013
  6. Junio C HamanoJul 24, 2013
  7. Jörn HeesJul 24, 2013
  8. Junio C HamanoJul 24, 2013
  9. Felipe ContrerasJul 25, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.