William Giokas 1007...@gmail.com writes:
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 1007...@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.
--
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
