Shipping hg-git by default?
Augie Fackler
raf at durin42.com
Sat Sep 26 14:29:24 UTC 2015
> On Sep 26, 2015, at 7:20 AM, Erik Huelsmann <ehuels at gmail.com> wrote:
>
> [snip]
>
>> 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
>>
> Completely agreed.
>
>> 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.
>>
> My point exactly. I was basically asking Augie for two things regarding such a scenario:
>
> 1) What would be his role in such a working group
> 2) What would be generally required from a group taking on development
Sorry, I didn’t see the part in this thread where anyone asked me questions - I kind of checked out. Anyway:
The big thing is that working with hg-git still exposes rough edges if you’re trying to do any sort of history rewriting. As soon as either side does that it gets very awkward and you (at least in my experience) have to be minimally conversant in both tools to straighten things out.
As far as shipping it with core? I honestly have no idea how people feel about that. I’m pretty much -0 on it, but if you can convince other people you stand a chance. Note that I could be more enthusiastic about it if people showed real motivation in patching hg-git, but as it stands it seems more or less all the users are happy with the state of things (based on patch flow.) The big hurdle in my mind is maintaining an “hg-like” workflow while you’re in hg land, but still being able to export things sensibly to git.
>> Part of the joy of open source is that if something is not what you need
>> or would like you CAN fix it.
>>
> True. And it's a real joy. However, to me the real joy in developing (with) Open Source software is that I can contribute back to the community that gave me the software and have my changes be beneficial to others as well (as opposed to just making my own changes for myself). The working group wouldn't be simply about "making changes" but also about "making changes that the wider community will adopt". Also, I'm hoping that Augie or some other core dev can help kick start such a group by defining actionable items.
I’m unmotivated to do any work on hg-git for two reasons:
1) I find the idea of trying to make a localgitrepo for Mercurial more interesting and challenging. The idea here would be that hg could work directly on git-format repos, and you’d see the git hashes. I’ve tinkered with this as a proof-of-concept, but it needs to be redone with performance in mind if someone actually wants to use it.
2) The bigger problem: I basically don’t have to use git. Essentially all my work is already in hg repositories, and the one-off projects not using hg are so seldom I just use hg-git or git depending on size and move on with life. I’d love to always be able to use hg for those, but it’s just not worth the effort to me personally. :(
>
> --
> Bye,
>
> Erik.
>
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150926/c947faea/attachment.asc>
More information about the Mercurial
mailing list