From: William Giokas <1007380@gmail.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Torsten Bögershausen" <tboegi@web.de>,
"Charles Brossollet" <chbrosso@lltech.fr>,
git@vger.kernel.org
Subject: Re: Error using git-remote-hg
Date: Tue, 13 May 2014 14:39:11 -0500 [thread overview]
Message-ID: <20140513193911.GG9051@wst420> (raw)
In-Reply-To: <53726e0355875_4aa4b312f892@nysa.notmuch>
[-- Attachment #1: Type: text/plain, Size: 3005 bytes --]
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
> William Giokas wrote:
> > On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
>
> > > Why do we "import changegroup" unconditionally, even though it
> > > is only used in the new codepath meant only for version 3.0 or
> > > higher, not inside the "if" block that decides if we need that
> > > module?
>
> > changegroup is prefectly /okay/ to import unconditionally, though as you
> > say it will never be used.
>
> As you say, it's perfectly OK.
But wrong. Yes, it works, but it's not how it should be done when we
have a code review such as this. It should simply not be done and makes
no sense to do with an 'if <check ver>; else' kind of thing later in the
application.
>
> > We can also be even more explicit with what we import by doing something
> > like::
> >
> > try:
> > from mercurial.changegroup import getbundle
> >
> > except ImportError:
> > def getbundle(__empty__, **kwargs):
> > return repo.getbundle(**kwargs)
>
> We could try that, but that would assume we want to maintain getbundle()
> for the long run, and I personally don't want to do that. I would rather
> contact the Mercurial developers about ways in which the push() method
> can be improved so we don't need to have our own version. Hopefully
> after it's improved we wouldn't have to call getbundle().
Assuming that mercurial <3.0 will not change, then this should never
need to change. Changes in 'getbundle' upstream would require changes
either way.
> Moreover, eventually there will be a Mercurial 4.0, even 5.0, and at
> some point we would want to remove the hacks for older versions. When we
> do so we would want the import to remain unconditionally, and remove the
> 'check_version(3, 0)' which is already helping to explain what the code
> is for without the need of comments.
The same exact thing can be done with this. In fact, it would probably
allow us to have better future-proofing with regards to new versions of
mercurial, there would just be different try:except statements at the
beginning.
>
> > I was really sad to see that, and didn't have time to really look at it
> > because of work and other projects, but I hope this presents a better
> > solution than the current patch.
>
> Either way Junio doesn't maintain this code, I do. And it's not
> maintained in git.git, git's maintained out-of-tree (thanks to Junio's
> decisions).
I still see it in git.git, and I will contribute this upstream for as
long as it is in the tree. If you want to use the patch that I sent to
this list, feel free.
> So please post your suggestions and patches to git-fc@googlegroups.com,
> and use the latest code at https://github.com/felipec/git-remote-hg.
Thanks,
--
William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
next prev parent reply other threads:[~2014-05-13 19:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-12 15:16 Error using git-remote-hg Charles Brossollet
2014-05-12 19:01 ` Torsten Bögershausen
2014-05-12 19:37 ` Felipe Contreras
2014-05-13 7:54 ` Charles Brossollet
2014-05-13 15:01 ` Torsten Bögershausen
2014-05-13 17:30 ` Junio C Hamano
2014-05-13 18:21 ` Felipe Contreras
2014-05-13 18:48 ` William Giokas
2014-05-13 19:09 ` Felipe Contreras
2014-05-13 19:39 ` William Giokas [this message]
2014-05-13 20:24 ` Felipe Contreras
2014-05-13 21:01 ` William Giokas
2014-05-13 22:16 ` Felipe Contreras
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140513193911.GG9051@wst420 \
--to=1007380@gmail.com \
--cc=chbrosso@lltech.fr \
--cc=felipe.contreras@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tboegi@web.de \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.