[Python-Dev] Move selected documentation repos to PSF BitBucket account?

[Nick Coghlan]

> 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   |   ncoghlan at gmail.com   |   Brisbane, Australia