Re: [PATCH] remote-hg: getbundle changed in mercurial 3.0

From: Junio C Hamano <gitster@pobox.com>
Date: May 13, 2014, 20:33 UTC
Message-ID: <xmqqzjilmnad.fsf@gitster.dls.corp.google.com>
In-Reply-To: <1400008359-18267-1-git-send-email-1007380@gmail.com>

William Giokas <1007380@gmail.com> writes:

Show 48 quoted lines

> In mercurial 3.0, getbundle was moved to the changegroup module, and
> gained a new argument. Due to this we cannot simply start using
> getbundle(...) imported from either one unconditionally, as that would
> cause errors in mercurial 3.0 without changing the syntax, and errors in
> mercurial <3.0 if we do change it.
>
> The try:except block at the beginning of git-remote-hg.py tries first to
> import mercurial.changegroup.getbundle, and if that fails we set the
> function 'getbundle' to work correctly with mercurial.repo.getbundle by
> removing the first argument.
>
> Signed-off-by: William Giokas <1007380@gmail.com>
> ---
>
> I have tested this briefly with mercurial 3.0, but have not yet really run
> through its paces. The tests that are included in next do pass with
> mercurial 3.0.
>
>  git-remote-hg.py | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/git-remote-hg.py b/git-remote-hg.py
> index 34cda02..3dc9e11 100755
> --- a/git-remote-hg.py
> +++ b/git-remote-hg.py
> @@ -14,6 +14,13 @@
>  
>  from mercurial import hg, ui, bookmarks, context, encoding, node, error, extensions, discovery, util
>  
> +try:
> +    from mercurial.changegroup import getbundle
> +
> +except ImportError:
> +    def getbundle(__empty__, **kwargs):
> +        return repo.getbundle(**kwargs)
> +
>  import re
>  import sys
>  import os
> @@ -985,7 +992,7 @@ def push_unsafe(repo, remote, parsed_refs, p_revs):
>      if not checkheads(repo, remote, p_revs):
>          return None
>  
> -    cg = repo.getbundle('push', heads=list(p_revs), common=common)
> +    cg = getbundle(repo, 'push', heads=list(p_revs), common=common)
>  
>      unbundle = remote.capable('unbundle')
>      if unbundle:

Thanks. I agree with you that this would probably be a better way to future-proof the code without unconditionally including what may not be used at all, as you said in the other thread.

I can be pursuaded to queue this particular patch for maintenance tracks after 2.0 final to my tree, but I do not think I would want to keep taking patches to this area myself in the longer run.

The way I envision the longer term shape of git-remote-hg.py in the contrib/ is either one of these two:

 (1) manage it just like contrib/hooks/multimail/, keeping a
     reasonably fresh and known-to-be-good snapshot, while making it
     clear that my tree is not the authoritative copy people should
     work off of;

 (2) treat it just like contrib/emacs/vc-git.el, which found a
     better home and left my tree at 78513869 (emacs: Remove the no
     longer maintained vc-git package., 2009-02-07); or

The first one may be more preferrable between the two, if only because distros would need time to adjust where they pick up the source material to package up, but it still needs cooperation with the "authoritative upstream" and this project to allow us to at least learn when the good time to import such good snapshots. In the case of vc-git, the separation was not about lack of will to coordinate, but because it was not necessary to keep it in my tree, as the "better home" was where the users expect to find the latest and greatest anyway.

If Felipe turns out to be a maintainer users do not trust for remote-hg, it is possible that you and other people can maintain it and work with git.git better by forking off of his tree. It is far early to know if that will be the case at this point, and I personally do not think that will happen (no, I do not have a concrete reason I can cite to explain why I think that way).

But even in such an extreme hypothetical case, the difference it makes to my tree would only be to take (1) or (2) and point to that forked remote-hg repository, instead of Felipe's, as the source of the "authoritative copy". And I wouldn't be taking individual patches directly to my tree in either case.