git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Jörn Hees" <dev@joernhees.de>
To: Antoine Pelisse <apelisse@gmail.com>
Cc: git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
	Felipe Contreras <felipe.contreras@gmail.com>
Subject: Re: [PATCH] remote-hg: Fix cloning and sharing bug
Date: Sun, 4 Aug 2013 14:17:20 +0200	[thread overview]
Message-ID: <478CA849-148C-4F73-A64F-9A5829523CC3@joernhees.de> (raw)
In-Reply-To: <1375612683-9104-1-git-send-email-apelisse@gmail.com>

Hi,

On 4 Aug 2013, at 12:38, Antoine Pelisse <apelisse@gmail.com> wrote:
> […]
> I also decided to always clone local repositories because what Jörn Hees
> said makes sense:
> If you have a local clone of a big repository, and then want to add a slow
> remote, you would have to reclone everything.
> I think the trade-off is good, because clone from local should not be that
> time expensive (maybe it can be on disk-space though).

I was working on a similar patch in the meantime, this point was the only thing that
kept me from submitting… Can someone of you think of an easy way to do this lazily
on the first non-local remote being added? 
In case we don't have a non-local clone (a mercurial dir with a clone subdir) yet, we
would try to go though the local mercurial remotes and then clone them… Just would
need a way to get their URLs. I thought about going through all "git remote -v" 
This way we wouldn't need to copy by default (bad for big repos), but could still do this
in a cheap way if a slow remote is added later on.

Btw, is there any reason why we don't just use the local mercurial remotes as shared
repo? Cause it's not under our git dir and might be deleted?


> […]
> contrib/remote-helpers/git-remote-hg |   47 ++++++++++++++++++++--------------
> 1 file changed, 28 insertions(+), 19 deletions(-)
> 
> diff --git a/contrib/remote-helpers/git-remote-hg b/contrib/remote-helpers/git-remote-hg
> index 0194c67..487c13d 100755
> --- a/contrib/remote-helpers/git-remote-hg
> +++ b/contrib/remote-helpers/git-remote-hg
> @@ -385,33 +385,42 @@ def get_repo(url, alias):
> 
>     extensions.loadall(myui)
> 
> -    if hg.islocal(url) and not os.environ.get('GIT_REMOTE_HG_TEST_REMOTE'):
> -        repo = hg.repository(myui, url)
> -        if not os.path.exists(dirname):
> -            os.makedirs(dirname)
> -    else:
> -        shared_path = os.path.join(gitdir, 'hg')
> -        if not os.path.exists(shared_path):
> +    hgdir = os.path.join(gitdir, 'hg')
> +    try:
> +        os.mkdir(hgdir)
> +    except OSError:
> +        pass
> +
> +    shared_path = os.path.join(hgdir, '.shared')

I thought we had agreed to use .git/hg as the shared directory before? (so that
a clone into that dir would end up in .git/hg/.hg instead of .git/hg/.shared/.hg)


> +    if not os.path.exists(shared_path):
> +        for remote in os.listdir(hgdir):
> +            try:
> +                hg.clone(myui, {}, os.path.join(hgdir, remote, 'clone'),
> +                         shared_path, update=False, pull=True)
> +                break
> +            except error.RepoError:
> +                pass
> +        else:

Elegant use of the for-else clause, but to my experience confuses many people.

This would also be the place to check for local remotes after not finding already
cloned non-local remotes (the lazy approach mentioned above). As this would
cause nested "for-else" loops, i'd rather repeatedly check for existence of .git/hg/.hg
and list the several fallback in order, the last one being this one:

>             try:
>                 hg.clone(myui, {}, url, shared_path, update=False, pull=True)
>             except:
>                 die('Repository error')

If you want i'll send around my patch as RFC.
In the end i don't care which one is accepted and how, most important that one is
accepted to fix the bug.

Cheers,
Jörn

  reply	other threads:[~2013-08-04 12:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-25  0:42 [PATCH v3] remotes-hg: bugfix for fetching non local remotes Joern Hees
2013-07-25 19:12 ` Felipe Contreras
2013-07-25 19:53   ` Antoine Pelisse
2013-07-25 20:40     ` Felipe Contreras
2013-07-25 21:10       ` Antoine Pelisse
2013-07-26  1:30         ` Junio C Hamano
2013-07-26 12:17         ` Jörn Hees
2013-08-04 10:38           ` [PATCH] remote-hg: Fix cloning and sharing bug Antoine Pelisse
2013-08-04 12:17             ` Jörn Hees [this message]
2013-08-04 13:31               ` Felipe Contreras
2013-08-04 13:51                 ` Jörn Hees
2013-08-04 14:00                   ` Felipe Contreras
2013-08-04 13:59                 ` Antoine Pelisse
2013-08-04 14:24                   ` Felipe Contreras
2013-08-04 13:22             ` Felipe Contreras
2013-07-26 12:16   ` [PATCH v3] remotes-hg: bugfix for fetching non local remotes Jörn Hees

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=478CA849-148C-4F73-A64F-9A5829523CC3@joernhees.de \
    --to=dev@joernhees.de \
    --cc=apelisse@gmail.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).