[Python-Dev] PEP: Collecting information about git

[Augie Fackler]

Oleg Broytman <phd <at> phdru.name> writes:


>
> Hi!

Hi! I work on Mercurial. I’ve got some inline responses, but I want to
summarize and put this in context for those without much energy for the topic.

There are a lot of reasons to prefer one tool over another. Common ones are
familiarity, simplicity, and power. Version control debates often touch all
three of those points, and there’s often a _lot_ of misinformation thrown
around during the debate. It’s very clear to me based on this thread that
Oleg is not familiar with Mercurial -- everything listed as impossible is
not only doable in Mercurial, but not infrequently the command or flag is
*identically named*. I’m sending this mail not in an attempt to combat what
may be a healthy move for the your development community, but instead to
ensure that the right capability tradeoffs are seen during this process.

If the Python community wants to move to Git (or, as is more often the case
with such migrations, GitHub specifically - the choice of Git is often
totally unrelated to the popularity of the one particular host), it should
do so for good, clear reasons. That might be everyone thinking Git is a
better tool (to my own personal dismay, I’ll admit), or it might be that the
perceived network effects of being hosted on GitHub outweigh the switching
costs or difficulty of using a more complex tool.

>
> On Sun, Sep 13, 2015 at 09:14:58AM +1000, Tim Delaney <timothy.c.delaney
<at> gmail.com> wrote:
> > On 13 September 2015 at 04:42, Oleg Broytman <phd <at> phdru.name> wrote:
> >
> > >    There are too many things that I personally can do with git but can't
> > > do with hg. Because of that I switched all my development from hg to git
> > > and I am willing to help those who want to follow.
> >
> > Slightly off-topic, but personally I'd love to know what those are. I've
> > yet to find anything in Git that I haven't been able to do at least as well
> > with Mercurial (or an extension), and there are things Mercurial
> > supports that I use extensively (in particular named branches and phases)
> > where the concept doesn't even exist in Git.
>

[elided much that is strictly personal preference, plus some personal history]

>    Git fixed all the problems I had with hg. Its branching model suits
> my understanding of branches much better.

So use bookmarks. They're almost identical.

> With git we can have
> per-directory .gitignore and .gitattributes. Lightweight and annotated
> tags point exactly to the commits they tag.

I'm chalking these up to personal taste, but know that the tagging behavior
of git vs hg is a very complicated tradeoff. Mercurial chose a path that
makes tags audit-able in the future, whereas in Git a tag could disappear
and it'd be hard to prove.


> Ability to pull and push between unrelated repos.

In my opinion, this is honestly a misfeature, but Mercurial absolutely can
do it:  `hg pull --force` will do what you want.

>    I learned commit editing and found that it was the thing I wanted so
> badly in hg. When I started Mercurial was at version 1.7 and there was
> no commit editing at all; there was ``hg rollback`` but it only could
> undo one transaction.

Please forget rollback exists. It's dangerous, and we're hiding it from new
users for a reason. :)
> Later Mercurial learned commit editing,
> unwillingly perhaps,

Not at all unwillingly, we're just trying to be deliberate about it. We
wanted to make sure that we *both* enabled editing by default, *and* make it
impossible for a user to lose data. Getting that right took time, but we
think the wait has been worth it. If you want a preview of where we’re
headed, take a look at
https://mercurial.selenic.com/wiki/ChangesetEvolution. Parts of it have
shipped, and the whole concept is making steady progress.

> but git is still better at it: ``git add -p``
> allows me to review and edit patches before commit while ``hg record``
> commits immediately.

FWIW, I totally *get* wanting a staging area. That said, other than the
staging area, record (aka commit --interactive) and git add -p are identical
functionality-wise. We also now ship (at least as of 3.5) a curses UI for
record, which is quite nice.

>    Git is powerful. Even now, at version 3.1 ``hg help log`` lists about
> a dozen of options; ``git help log`` gives me about 60 pages of
> documentation.

Counting number of command line flags is a horrible way to compare power of
the tool. It reflects complexity, not power.

Mercurial has two major concepts--revsets and templates--that repeat over
and over, and which eliminate the need for many command-line flags that Git
has to include. I’ll give some examples below, but I’d also like to point
out that if you'd read recent Mercurial (3.5 is current - you looked at a
version that’s over a year old by now) output for 'hg help log', you'd find
many options are quite powerful. See below.

> I do not use all of them but I very much like
> ``git log --decorate``

This can be done with our templating system - I even have it in my hgrc. We
should include some better templates with hg, so I'll take an action item
here on this, but it's possible.

> ``--graph``

Had this for years and it’s even the same option!

> ``--grep=`` (and all related search options,
> especially ``-G``)

Remember how I mentioned revsets replace a lot of Git command line flags?
This is an example. hg help -r 'grep(foo)'. See also `hg help revsets`,
which are a very rich query system for revision history usable throughout
mercurial rather than only in log.

> ``--pretty``, ``--oneline``,

These are again just templates. `hg help templating`, and see above about us
maybe wanting some more built-in styles.

> ``--encoding=`` (I
> often use koi8-r instead of utf-8),

I believe we normoally infer encoding from your locale. Is that the wrong
thing for you for some reason?

That said, ‘hg help -v | grep encoding’ would have helped you find our
`--encoding` flag.

> ``--color``

[extensions]
color=

(shipped with hg for years, off by default because it breaks poorly written
scripts)

> and ``--word-diff``. I
> like ``git grep``, especially in the form ``git grep -Ovim``.

I'll admit, git-grep is a decent feature, but I find grep(1) or ack to be
just fine.

> I don't
> know what are the equivalent commands for ``git commit -c HEAD~``

hg commit --amend, or use hg histedit (which is like rebase -i)

> or
> ``git diff --name-only``.

hg status --no-status

>    Git has a lot of good documentation.

Honestly so does Mercurial.

[elided anecdote]

>
>    As I stopped using Mercurial I do not understand what phases are.
> they are phases of commit according to what? To the origin (let me
> borrow the word from git terminology)?

Commits seen in the main public repository are marked as public, and
Mercurial refuses to edit them. Most history rewriting woes happen when
people rewrite widely shared history and force push the new version.
Disallowing non-fast-forward push on the server prevents the rewriting from
propagating unintentionally. Phases proactively prevent users from shooting
themselves in the foot.

More details here https://www.logilab.org/blogentry/88203


>
>    Mercurial, for sure, has some advantages. It is written in Python.
> That's important. That's important for ideological reasons. That's also
> important because hg runs natively under Windows, it even has code for
> working with case-insensitive filesystems.
>    There are Mercurial Queues.
>    There are also small advantages like better polished command-line
> interface and ability to shorten command names and options to a unique
> prefix.

I'd actually go so far as saying that a better polished CLI is a *huge* win,
and the fact Mercurial's Windows support is more mature is also a pretty big
win for something cross-platform.

You’re talking about a tool that you use every day. Having a good UI
out-of-the-box is a huge benefit in that situation. Honestly, having a good
UI is part of why Python itself became so popular.

Sometimes, you have to give up power to get an easier user interface, but I
hope I’ve shown in this email that Mercurial gives you both a better UI, and
more power. There is no sacrifice other than familiarity--and because
Mercurial indeed has as simpler UI, closing the familiarity gap from Git to
Mercurial is much easier than the other way around.

If Python crew wants to go to Git, then it should go to Git, but it should
want to go for legitimate reasons--not a misguided belief that Git can do
things Mercurial cannot.

>
> > Tim Delaney
>
> Oleg.