Shipping hg-git by default?

Steve (Gadget) Barnes gadgetsteve at hotmail.com
Sat Sep 26 10:26:48 UTC 2015



On 26/09/2015 11:06, Erik Huelsmann wrote:
> 
> On Fri, Sep 25, 2015 at 4:35 PM, Augie Fackler <lists at durin42.com
> <mailto:lists at durin42.com>> wrote:
> 
>     On Fri, Sep 25, 2015 at 10:28 AM, anatoly techtonik
>     <techtonik at gmail.com <mailto:techtonik at gmail.com>> wrote:
>     > Hi,
>     >
>     > Looks like https://bitbucket.org/ ditched Mercurial:
>     >
>     >     Bitbucket is the Git solution for professional teams
>     >
>     > So for me personally there is no incentive to use HG
>     > anymore (even though I really miss 'hg inc`), especially
>     > when I setup new virtual machine on Cloud9 or similar
>     > platform to quickly patch and test one of my projects.
>     >
>     > But.. if installation of Mercurial already included hg-git
>     > support, I could still use it to work with GitHub right of
>     > the box without an additional installation hassle, which
>     > is, of course, putting me away from that at the moment.
>     >
>     > What do you say?
> 
>     hg-git needs a ton of work to be viable for inclusion like this. It'd
>     need things like better handling of history rewriting (incl. some
>     modicum of phases support, as well as coping with rewrites on the git
>     side more gracefully), and probably also a fair amount of UI spit and
>     polish.
> 
> 
> I think you're unnecessarily harsh on yourselves here. I use hg-git
> every day, have done so for more than a year, and it works great! The
> only issue that I have with it has to do with a very specific situation
> where HG commit hashes are incorrectly (not) translated to Git hashes.
> Other than that, no problems.
> 
> You might argue that I ought to switch to Git. I don't want to though:
> from a user's perspective, Hg feels much more polished and tuned to *my*
> processes than Git. Git feels like I'm handed the Lego bricks and I need
> to make my own composed commands and processes out of it. Hg just offers
> me a complete and comprehensible workflow. So, as long as I don't *have*
> to switch to Git, I'm really happy to keep using Mercurial, with a mix
> of repositories, both Hg and Git. (Unfortunately, with more of he latter
> than the former.)
> 
>     Even then, I'm not sure it makes complete sense, but it's pretty
>     academic unless someone wants to invest that kind of time into hg-git
>     (I don't personally have the time or motivation.)
> 
> 
> From the reactions on this thread, it looks like it makes complete sense
> to a number of people :-)
> 
> What does the above remark about time and motivation mean in the longer
> term though? I mean, do you still have time to update your repository if
> you should get pull requests that are up to your standards? If not,
> would there be ways to organize future development nonetheless? You seem
> to imply that one person should be picking up the development, however,
> if there are small enough actionable items, maybe many people can make a
> difference together?
> 
> Thanks for your work on the module so far!
> 
> Regards,
> 
> -- 
> Bye,
> 
> Erik.
> 
> http://efficito.com <http://efficito.com/> -- Hosted accounting and ERP.
> Robust and Flexible. No vendor lock-in.
> 
> 
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> https://selenic.com/mailman/listinfo/mercurial
> 

At my work we have central severs that offer only SVN, git & CVS for
historical reasons - but I use, (a slightly modified version for dealing
with relative external path), hgsubversion to great effect & am looking
forward to using hg-git likewise.

While I can and do use git I much prefer the use of mercurial and while
I would love it if hg-git was a default installation, or just a little
easier to get working on Windows, I can also appreciate that the main hg
developers have a limit on what they can handle alone so if sufficient
people are interested in getting hg-git to a point where it can be
included by default why not try to set up a working group to put the
polish on both the tool and the test suite to the point where adding it
by default becomes a simple matter of throwing a switch.

Part of the joy of open source is that if something is not what you need
or would like you CAN fix it.

-- 
Steve (Gadget) Barnes
Any opinions in this message are my personal opinions and do not reflect
those of my employer.



More information about the Mercurial mailing list