Python Goes Mercurial

Discussion in 'Python' started by Lawrence D'Oliveiro, Apr 1, 2009.

  1. <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-mercurial-version-control-system.ars>

    So what were these "strong antipathies" towards Git, exactly?
    Lawrence D'Oliveiro, Apr 1, 2009
    #1
    1. Advertising

  2. In message <>, andrew
    cooke wrote:

    > Lawrence D'Oliveiro wrote:
    >> <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-

    mercurial-version-control-system.ars>
    >>
    >> So what were these "strong antipathies" towards Git, exactly?

    >
    > i haven't read the article you link to, but compared to what i've read on
    > dev "strong antipathies" sounds a bit over-hyped.


    That was the phrase used by GvR.
    Lawrence D'Oliveiro, Apr 1, 2009
    #2
    1. Advertising

  3. Lawrence D'Oliveiro

    John Yeung Guest

    Lawrence D'Oliveiro and andrew cooke exchanged:

    > >>> So what were these "strong antipathies" towards Git, exactly?

    >
    > >> compared to what i've read on dev
    > >> "strong antipathies" sounds a bit over-hyped.

    >
    > > That was the phrase used by GvR.

    >
    > well if you find any, please do report back.


    Andrew, perhaps you stopped reading too early. Here's one that
    clearly expresses strong antipathy:

    http://mail.python.org/pipermail/python-dev/2009-March/087971.html

    (When challenged, he later goes on to claim "Internet hyperbole",
    which I'll buy.)

    John
    John Yeung, Apr 1, 2009
    #3
  4. Lawrence D'Oliveiro

    Terry Reedy Guest

    Lawrence D'Oliveiro wrote:
    > <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-mercurial-version-control-system.ars>
    >
    > So what were these "strong antipathies" towards Git, exactly?


    The relevant PEP is http://www.python.org/dev/peps/pep-0374/
    To some Pythonic eyes, the git command syntax in the examples given is
    less graceful.

    Another thing mentioned in the py-dev thread. Git apparently allows
    'changing history' by changing the underlying directed acyclic graph.
    Some like that, some do not. (I do not completely understand this, but
    you asked...)

    tjr
    Terry Reedy, Apr 1, 2009
    #4
  5. In message <>, Terry Reedy wrote:

    > Lawrence D'Oliveiro wrote:
    >> <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-mercurial-version-control-system.ars>
    >>
    >> So what were these "strong antipathies" towards Git, exactly?

    >
    > The relevant PEP is http://www.python.org/dev/peps/pep-0374/


    Useful link, though it seems incomplete.

    Interesting phrase "To make up for svn's lack of cheap branching"--it's not the branching that's the problem in Subversion, it's the merging. :)

    > Git apparently allows 'changing history' by changing the underlying
    > directed acyclic graph.


    Every object in a Git repository is identified by the SHA-1 hash of its entire contents. For a commit object, that includes the references to its parent commit(s). Thus,
    there's no way <http://wlug.org.nz/VeryImpossible> to change these while preserving the identity of the commit object.

    Yes, it's easy with the low-level Git commands to go back and synthesize past history, but you can't hide the fact that you've done so. One of the design goals of Git
    was guaranteeing the integrity of the entire commit history.
    Lawrence D'Oliveiro, Apr 1, 2009
    #5
  6. Lawrence D'Oliveiro, Apr 1, 2009
    #6
  7. Lawrence D'Oliveiro

    Paul Rubin Guest

    Terry Reedy <> writes:
    > > So what were these "strong antipathies" towards Git, exactly?

    >
    > The relevant PEP is http://www.python.org/dev/peps/pep-0374/


    Interesting. I'm on a project that switched from Mercurial to Git
    recently. I don't have much of a sense of the relevant differences
    but other people on the project seemed to prefer Git rather strongly.
    Git does seem to faster, contrary to the measurements in that PEP.
    Paul Rubin, Apr 1, 2009
    #7
  8. Lawrence D'Oliveiro

    Carl Banks Guest

    On Mar 31, 6:25 pm, Lawrence D'Oliveiro <l...@geek-
    central.gen.new_zealand> wrote:
    > <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-mer...>
    >
    > So what were these "strong antipathies" towards Git, exactly?


    Apparently Mercurial had it's own hate club, and the reaction on
    python-dev was so severe GvR backtracked on his decision.

    Trying to appease a least common denominator, he changed his mind and
    Python is going with SCCS instead.


    Carl Banks
    Carl Banks, Apr 1, 2009
    #8
  9. Lawrence D'Oliveiro

    Chris Rebert Guest

    On Wed, Apr 1, 2009 at 12:01 AM, Carl Banks <> wrote:
    > On Mar 31, 6:25 pm, Lawrence D'Oliveiro <l...@geek-
    > central.gen.new_zealand> wrote:
    >> <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-mer....>
    >>
    >> So what were these "strong antipathies" towards Git, exactly?

    >
    > Apparently Mercurial had it's own hate club, and the reaction on
    > python-dev was so severe GvR backtracked on his decision.
    >
    > Trying to appease a least common denominator, he changed his mind and
    > Python is going with SCCS instead.


    This is why I hate staying up late on March 31st...

    Cheers,
    Chris

    --
    I have a blog:
    http://blog.rebertia.com
    Chris Rebert, Apr 1, 2009
    #9
  10. Lawrence D'Oliveiro

    Paul Boddie Guest

    On 1 Apr, 08:18, Paul Rubin <http://> wrote:
    > Terry Reedy <> writes:
    > > > So what were these "strong antipathies" towards Git, exactly?

    >
    > > The relevant PEP ishttp://www.python.org/dev/peps/pep-0374/

    >
    > Interesting.  I'm on a project that switched from Mercurial to Git
    > recently.  I don't have much of a sense of the relevant differences
    > but other people on the project seemed to prefer Git rather strongly.
    > Git does seem to faster, contrary to the measurements in that PEP.


    From what I've seen by browsing the blogs of various large
    communities, there always seems to be large numbers of Git advocates
    (although "fanboys" might be a more accurate term in numerous cases)
    ready to crowd out blog comments with single line insistences that
    projects switch to Git. Indeed, I've even seen something resembling an
    advocacy site for Git where there's a comparison to Mercurial and
    Bazaar, although the benchmarks seem to be done with a certain amount
    of honesty. Consequently, many projects seem to choose Git either on
    the basis of what other people have supposedly done, or on the "hacker
    cred" supposedly conferred through its association with Linus
    Torvalds.

    I've also heard various tales of Git usage where "strong antipathies"
    would be a fairly accurate summary of user experiences, and this is
    where such experiences can be contrasted with solid experiences with
    other version control systems. And I've heard stories of "bait and
    switch" with Git: "you can do XYZ with Git but not with ..." followed
    by the discovery that you can't realistically do XYZ with Git, either.
    Such advocacy makes me deeply cynical about Git.

    To be fair, Git usability has apparently come some way since, say,
    2006 when I first encountered Git and Mercurial, with the former being
    recommended by the guys who develop itools (whose judgement I
    generally trust) but with the caveat that one used the Cogito front-
    end at that time, and the latter by the guys who develop MoinMoin
    (whose judgement I also trust). The difference between the two DVCSs
    as far as I have seen is that Mercurial has always been as usable as
    it is today without additional tools. In addition, there seems to be
    more honesty from the Mercurial community about what Mercurial can and
    cannot support, as opposed to the disinformation cloud (or perhaps
    uninformation cloud) that seems to surround Git.

    As for the performance of these tools, you wouldn't think Mercurial
    was written in Python (admittedly with some C) and Git was written in
    C looking at various benchmarks. For what it's worth, this BDFL
    decision is one I actually agree with.

    Paul
    Paul Boddie, Apr 1, 2009
    #10
  11. Lawrence D'Oliveiro

    Tim Daneliuk Guest

    Carl Banks wrote:
    > On Mar 31, 6:25 pm, Lawrence D'Oliveiro <l...@geek-
    > central.gen.new_zealand> wrote:
    >> <http://arstechnica.com/open-source/news/2009/03/python-adopts-the-mer...>
    >>
    >> So what were these "strong antipathies" towards Git, exactly?

    >
    > Apparently Mercurial had it's own hate club, and the reaction on
    > python-dev was so severe GvR backtracked on his decision.
    >
    > Trying to appease a least common denominator, he changed his mind and
    > Python is going with SCCS instead.
    >
    >
    > Carl Banks


    ;)


    A few years ago I had a very large client - many multi-billions of
    dollars in revenue annually - that ran their entire custom IT
    system from a home grown variant of SCCS. It did work, but when
    I suggested that better open source tools existed, they kindly
    explained their complete lack of interest in moving several millions
    of lines of code to anything new. Go figure.

    --
    ----------------------------------------------------------------------------
    Tim Daneliuk
    PGP Key: http://www.tundraware.com/PGP/
    Tim Daneliuk, Apr 1, 2009
    #11
  12. In message <>, Tim Daneliuk wrote:

    > ,,, when I suggested that better open source tools existed, they kindly
    > explained their complete lack of interest in moving several millions
    > of lines of code to anything new.


    What was their explanation?
    Lawrence D'Oliveiro, Apr 2, 2009
    #12
  13. In message <7a1dd0d8-1978-470b-
    >, Paul Boddie wrote:

    > And I've heard stories of "bait and
    > switch" with Git: "you can do XYZ with Git but not with ..." followed
    > by the discovery that you can't realistically do XYZ with Git, either.


    Cite?
    Lawrence D'Oliveiro, Apr 2, 2009
    #13
  14. Lawrence D'Oliveiro

    Tim Daneliuk Guest

    Lawrence D'Oliveiro wrote:
    > In message <>, Tim Daneliuk wrote:
    >
    >> ,,, when I suggested that better open source tools existed, they kindly
    >> explained their complete lack of interest in moving several millions
    >> of lines of code to anything new.

    >
    > What was their explanation?
    >


    Their entire internal workflow from development through final release
    and deployment was built around these ancient/nonstandard toolset. It
    was economically infeasible to retool both the technology and the
    processes for millions of lines of code under version control - there
    just wasn't an ROI for it. This is not uncommon in large legacy
    environments in my experience.


    --
    ----------------------------------------------------------------------------
    Tim Daneliuk
    PGP Key: http://www.tundraware.com/PGP/
    Tim Daneliuk, Apr 2, 2009
    #14
  15. Lawrence D'Oliveiro

    Paul Boddie Guest

    On 2 Apr, 04:27, Lawrence D'Oliveiro <l...@geek-
    central.gen.new_zealand> wrote:
    > In message <7a1dd0d8-1978-470b-
    >
    > >, Paul Boddie wrote:
    > > And I've heard stories of "bait and
    > > switch" with Git: "you can do XYZ with Git but not with ..." followed
    > > by the discovery that you can't realistically do XYZ with Git, either.

    >
    > Cite?


    Well, I "heard" stories rather than read them, so I can't cite them,
    but I believe that one argument crafted to favour Git was that it is
    great for history editing, but it turns out that it isn't so great, as
    the following commentary points out:

    "You can do it, but as soon as you go to merge with another repo that
    had the unedited commit history, you’ll bump into weirdness (and
    probably invalidate your whole reason for rebasing, which was to clean
    up the history)."

    - http://adam.blog.heroku.com/past/2008/6/30/rebasing_is_editing_commits/

    I'm sure other people have their own tales of a similar nature.

    Paul
    Paul Boddie, Apr 2, 2009
    #15
  16. On Thu, Apr 2, 2009 at 9:12 PM, Paul Boddie <> wrote:

    >
    > "You can do it, but as soon as you go to merge with another repo that
    > had the unedited commit history, you’ll bump into weirdness (and
    > probably invalidate your whole reason for rebasing, which was to clean
    > up the history)."
    >
    >  - http://adam.blog.heroku.com/past/2008/6/30/rebasing_is_editing_commits/
    >
    > I'm sure other people have their own tales of a similar nature.


    It is explained in this article why rebase can't be used for something
    which will be the base for upcoming merges; not all branches are
    intended this way (but most public ones are). I would say this shows
    one feature which I think matters a lot in git, more than rebasing
    itself: multiple branches in a repo, and very cheap branching (in CPU
    cost, space and workflow) so that you can use private branches for
    experimentation.

    cheers,

    David
    David Cournapeau, Apr 2, 2009
    #16
  17. Lawrence D'Oliveiro

    Kay Schluehr Guest

    On 1 Apr., 07:56, Lawrence D'Oliveiro <l...@geek-
    central.gen.new_zealand> wrote:
    > In message <35d429fa-5d13-4703-
    >
    > >, John Yeung wrote:
    > > Here's one that clearly expresses strong antipathy:

    >
    > > http://mail.python.org/pipermail/python-dev/2009-March/087971.html

    >
    > There are lots of GUI- and Web-based front ends to Git. And look at on-line
    > services like GitHub and Gitorious. The level of support for it is huge.


    Ironically Mercurials most popular UI frontend Tortoise is going to
    crash Python tools ( like Wing-IDE ) on Windows. That's a known issue
    for about a year and more and the developers are not inclined to fix
    it. This doesn't really increase my trust that Mercurials UI tools are
    of a higher quality than Git's no matter which platform is used.
    Kay Schluehr, Apr 2, 2009
    #17
  18. Lawrence D'Oliveiro

    David Smith Guest

    Kay Schluehr wrote:
    > On 1 Apr., 07:56, Lawrence D'Oliveiro <l...@geek-
    > central.gen.new_zealand> wrote:
    >> In message <35d429fa-5d13-4703-
    >>
    >> >, John Yeung wrote:
    >>> Here's one that clearly expresses strong antipathy:
    >>> http://mail.python.org/pipermail/python-dev/2009-March/087971.html

    >> There are lots of GUI- and Web-based front ends to Git. And look at on-line
    >> services like GitHub and Gitorious. The level of support for it is huge.

    >
    > Ironically Mercurials most popular UI frontend Tortoise is going to
    > crash Python tools ( like Wing-IDE ) on Windows. That's a known issue
    > for about a year and more and the developers are not inclined to fix
    > it. This doesn't really increase my trust that Mercurials UI tools are
    > of a higher quality than Git's no matter which platform is used.


    The conflict between TortoiseHg and Wing IDE can be fixed by simply
    uninstalling the Tortoise Overlays. You loose the graphic overlay on
    folders, but otherwise everything works.

    --David
    David Smith, Apr 2, 2009
    #18
  19. Lawrence D'Oliveiro

    Kay Schluehr Guest

    On 2 Apr., 15:05, David Smith <> wrote:
    > Kay Schluehr wrote:
    > > On 1 Apr., 07:56, Lawrence D'Oliveiro <l...@geek-
    > > central.gen.new_zealand> wrote:
    > >> In message <35d429fa-5d13-4703-

    >
    > >> >, John Yeung wrote:
    > >>> Here's one that clearly expresses strong antipathy:
    > >>> http://mail.python.org/pipermail/python-dev/2009-March/087971.html
    > >> There are lots of GUI- and Web-based front ends to Git. And look at on-line
    > >> services like GitHub and Gitorious. The level of support for it is huge.

    >
    > > Ironically Mercurials most popular UI frontend Tortoise is going to
    > > crash Python tools ( like Wing-IDE ) on Windows. That's a known issue
    > > for about a year and more and the developers are not inclined to fix
    > > it. This doesn't really increase my trust that Mercurials UI tools are
    > > of a higher quality than Git's no matter which platform is used.

    >
    > The conflict between TortoiseHg and Wing IDE can be fixed by simply
    > uninstalling the Tortoise Overlays. You loose the graphic overlay on
    > folders, but otherwise everything works.
    >
    > --David


    Good to know. Uninstalling a major feature that enhances usability
    just to make it usable isn't much less ironic though.
    Kay Schluehr, Apr 2, 2009
    #19
  20. Lawrence D'Oliveiro

    Kay Schluehr Guest

    > Meh. Use the command line like God intended.

    I'm sorry to say this Rhodri but there is probably no god ;)

    The reason I like overlays is that they are data displays that
    highlight changes without letting me do any action. The VCS works for
    me before I'm doing any work with it and that's a good thing because
    I'm *always* lazy.
    Kay Schluehr, Apr 3, 2009
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Larry Hastings
    Replies:
    0
    Views:
    363
    Larry Hastings
    Jan 11, 2007
  2. Replies:
    1
    Views:
    334
    Dennis Lee Bieber
    Mar 3, 2007
  3. Replies:
    1
    Views:
    294
    Joshua Cranmer
    Jan 18, 2008
  4. Alia Khouri
    Replies:
    1
    Views:
    218
    Alia Khouri
    Jul 16, 2008
  5. Martin v. Löwis

    Mercurial migration: help needed

    Martin v. Löwis, Aug 18, 2009, in forum: Python
    Replies:
    0
    Views:
    263
    Martin v. Löwis
    Aug 18, 2009
Loading...

Share This Page