Re: [PATCH v4 00/13] New remote-hg helper
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Nov 4, 2012, 02:28 UTC
- Message-ID
- <CAMP44s0wJPqKBVyS-npe7uNEO3EBPH_xUVvzzWd4wCua4gxp9Q@mail.gmail.com>
- In-Reply-To
- <CAMP44s0DyiH+ac-xnfmJ3+JSib+y8GYZZymM83HUjKi5CuqARg@mail.gmail.com>
On Fri, Nov 2, 2012 at 8:20 PM, Felipe Contreras <felipe.contreras@gmail.com> wrote:
Show 17 quoted lines
> On Fri, Nov 2, 2012 at 7:39 PM, Felipe Contreras > <felipe.contreras@gmail.com> wrote: > >> As a rule, I don't see much value in writing a framework that works >> only for one case, that smells more like over-engineering. If we had >> two cases (hg and bzr), then we might be able to know with a modicum >> of certainty what such a framework should have. So I would prefer to >> have two standalone remote-helpers, and _then_ do a framework to >> simplify both, but not before. But that's my personal opinion. >> >> Now that I have free time, I might be able to spend time writing such >> a proof-of-concept remote-bzr, and a simple framework. But I would be >> concentrated on remote-hg. > > Actually, there's no point in that; there's already a git-remote-bzr: > > http://bazaar.launchpad.net/~bzr-git/bzr-git/trunk/view/head:/git-remote-bzr
Turns out the quality of that tools is not that great, so I decided to write a simple one using bzr-fastimport. It works nicely, although I wouldn't trust the quality of bzr-fastimport too much.
It's so simple I don't see the need of a framework, but if needed, one could be done taking these git-remote-{hg,bzr} as a basis.
Cheers.
-- Felipe Contreras