Fwd: Switch to git?

Martin Geisler martin at geisler.net
Sun Nov 24 12:18:45 CST 2013


Angel Ezquerra <angel.ezquerra at gmail.com> writes:

> On Sat, Nov 16, 2013 at 8:16 AM, Lester Caine <lester at lsces.co.uk> wrote:
>> anatoly techtonik wrote:
>>>
>>> Anyway, I am getting upset every
>>> time when I am forced to use Git for Python, because users just don't
>>> care.
>>
>> Personally hg-git does everything I need to cooperate with the leamings ...
>> even when one presents a good case for hg, git still gets adopted 'As it has
>> a better takeup' ... let them think that and just use the tools you want
>> locally :)
>
> I just went through Martin's excellent reply on the thread that
> Anatoly mentioned:
>
> https://groups.google.com/forum/#!msg/codereview-discuss/ilUffSph68I/NCldEt2Ii-4J
>
> As usual, Martin's post is amazingly clear and informative.
>
> I also read Robbie Iannucci's answer to Martin:
>
> https://groups.google.com/d/msg/codereview-discuss/ilUffSph68I/hVE5WvsUG1sJ
>
> In it Robbie mentioned something that I think is worth considering.
> Basically he said that it was not clear to him (and I assume that to
> many other people) that the core extensions that ship with mercurial
> are as well maintained as the rest of mercurial's commands. He said
> that he was scared to enable them because in the git world even first
> party extensions are somewhat flaky and because he did not know if
> these extensions could change the behavior of core hg commands in
> subtle ways.
>
> My take from Robbie's comment is that when in the past we have
> discussed "how hard is it to open an editor and enable the
> extensions?" perhaps we were missing the point a little. Maybe the
> point is not how hard is to enable the extensions. Maybe the point is
> that some users are scared to enable _any_ extension in the first
> place, no matter how easy it is to enable them.

Yes, I think that is a good point! People always moan when I tell them
that they have to turn on extension X, Y, and Z. To many, extensions
sound like something less stable. It's not the first thing they want to
use when they start a new tool. In some cases it's good that they don't
run off and play with MQ as the first thing -- in other cases (e.g.,
when coming from Git) it's bad that they don't see 'hg rebase'.

Perhaps we could begin advertising the extensions in the core help
texts. Something like mentioning rebase in 'hg help merge' and
mentioning record in 'hg help commit'.

Alternatively, maybe we could let commands from (some) extensions show
up in 'hg help'. Something like that would make Mercurial seem more
feature complete out of the box, without compromising the plugable
system with a core part and an extension part.

We might even be able to go further... When I first explained that
Mercurial had extensions to a colleague, he had then expected that
commands like 'hg add', 'hg commit', etc were also provided by an
extension -- the "core" extension that is always loaded.

I had never considered that, but it kind of makes sense. We could split
the gigantic commands.py file up into separate "extensions" which are
loaded by default. Perhaps we could then make 'hg rollback' a command in
an extension called "core-dangerous" which isn't loaded by default. Just
some ideas... :)

> In his reply Robbie made a couple of suggestions in this regard that
> perhaps are worth considering:
>
> - Mark official extensions even more loudly. Perhaps they could be
> shown on the main "hg help" text. Perhaps the official extensions
> could be marked as so in "hg help extensions", etc.
> - Ship a "git_mode" script that enabled (he said install, which I
> think is very telling) the scripts that make hg behave a bit more like
> git (i.e. rebase, histedit, etc).

We could check if the user has a large Git config file -- if so, we
create a ~/.hgrc file with rebase and histedit enabled when Mercurial is
first run :)

-- 
Martin Geisler

http://google.com/+MartinGeisler | http://careers.stackoverflow.com/mg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial/attachments/20131124/849ff906/attachment.pgp>


More information about the Mercurial mailing list