> On Nov 23, 2014, at 1:49 AM, Nick Coghlan wrote: >>> >>> I took the git knowledge I acquired by necessity at Red Hat and >>> figured out how to apply it to hg. All the same features are there in >>> hg, they're just switched off by default (mainly because the core >>> Mercurial devs are adamant that any potentially history destroying >>> operation in a version control system must be opt-in). > > If you could find the time to write up something about that I'm sure it would > be helpful. :)
The main thing is to enable some of the extensions mentioned in http://mercurial.selenic.com/wiki/GitConcepts#Command_equivalence_table by adding the appropriate entries to ~/.hgrc. A subset of my own extension set: ============== [extensions] rebase = share = eol = histedit = record = purge = ============== Share (multiple working directories from a single clone) is nice for a multi-branch project like CPython, while record allows selective commits, rebase allows changeset rebasing (as you might expect), histedit allows interactive history editing (akin to git's interactive rebasing), and pure allows deleting commits entirely. eol is the extension for Windows end of line handling that CPython needs. Several of those are off by default due to Mercurial's policy that anything which risks losing data should be off by default - messy history is considered preferable to potentially losing changes you didn't mean to destroy. git, by contrast, is happy to let users destroy history, and considers it their own fault if they mess it up and lose content irrevocably - thus the plethora of "how to use git safely" guides, while there's a relative dearth of "how to enable history modification in Mercurial" guides. The Mercurial team's preferred solution to history modification is changeset evolution, which also version controls any history editing operations so they can be reliably communicated to other users of a shared repo: http://evolution.experimentalworks.net/doc/user-guide.html While that's officially still experimental, it's unlikely to pose significant hazards to anyone coming to Mercurial from git - git's default mode of operation is far more cavalier regarding repository history than evolve will ever be. Another aspect that can be somewhat annoying is the terminology conflict between branches in the git sense and bookmarks vs named branches in the Mercurial sense. In Mercurial, commits made on a branch permanently remember which branch they were made on - you can see in the CPython history, for example, whether a particular commit was made to the 2.7 branch, or the 3.3 branch, etc, just by looking at the commit in isolation. Mercurial bookmarks and git branches, by contrast, are just references to a particular commit that represents the current head of a particular line of development - to find out if a particular commit is on that line of development, you have to trace the commit graph backwards to see if it appears. For a while, Mercurial was also missing support for git-style revision shorthands (you needed an extension to add them), but these days you can do things like "hg diff -r tip^" or "hg diff -r 'p1()^'" to specify relative revset references (while still retaining the full flexibility of Mercurial's programmatic revset syntax if you need it). (Speaking of which, I remembered one key thing which would likely be broken by a switch in the underlying DVCS: the Reitveld/Roundup integration) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
