
Mercurial RFC of a new extension to directly operate on Git repositories - luu
https://phab.mercurial-scm.org/D6734
======
yjftsjthsd-h
Explicitly super early, but if this got mature it would be really nice since
Mercurial has a much nicer UX IMO. So I'd be very happy to use hg to control
all of my git repositories. (I'd generally prefer to just use hg for
everything, but unfortunately network effects are murder on tools that are
explicitly meant for collaboration and integration; there isn't really a
"mercurialhub", CI/CD support is lacking, etc.)

~~~
mehrdadn
For those of us who don't know Mercurial -- how is the UX better than git's?
Are there examples you can use to illustrate? (I've heard this frequently but
never had a chance to really learn it.)

~~~
umvi
Well, the biggest UX fail for me on git was the ambiguous and counter
intuitive use of the command `checkout`. I've heard the latest versions of Git
mitigate this with `git switch` and `git restore` but seriously `git checkout`
is the most confusing command ever. Just attempt to describe to an SVNer what
`git checkout` does in one sentence or less.

I haven't used Hg, but I'm guessing it doesn't have anything as bad as
checkout.

~~~
grumpydba
In 5 years from now, will there still be svners?

~~~
umanwizard
FreeBSD uses SVN, and it is unlikely that they would ever move to git or
mercurial, since they try to minimize the amount of copyleft code in the base
system (e.g., they moved to Clang instead of GCC a few years ago)

~~~
_-david-_
FreeBSD is looking into moving to Git.

[https://wiki.freebsd.org/Git](https://wiki.freebsd.org/Git)

~~~
umanwizard
Interesting... why?

------
theamk
It'd be interesting to see how they deal with unnamed heads.

git creates them in the background pretty frequently, and expects them to be
invisible to user (for example during many rebases or when viewing remote
repositories, or when pulling remote changes)

mercurial creates them in response to user action, displays them to user by
default, and expects users to care about them.

~~~
pdonis
This is only one of a number of differences in the underlying ontologies of
mercurial and git. Another is branches: git repositories have no concept of a
"branch" in the mercurial sense, what git calls a "branch" is more like an hg
bookmark. I'm not sure how a tool like this can deal with such things without
either disabling some hg functionality or adding metadata to keep track of the
hg stuff that git doesn't track.

~~~
sfink
The branch is a wad of metadata included in (attached to?) the commit. It'll
somehow have to roundtrip the various metadata.

I doubt it'll ever be 100% complete, but you should be able to get quite a
ways. Certainly far enough to make it work using github as your repo of record
(and as someone who regularly submits github PRs via hg-git, I have evidence
that it can work.)

------
dreamcompiler
I really hope this becomes a debugged real tool. Mercurial's UI makes
intuitive sense and git's is just a bunch of magic incantations. Git's builtin
help and documentation are also useless. I can easily use Mercurial offline
without a Google search window open. That's impossible for me with git.

~~~
acdha
Having used both extensively, that sounds awfully hyperbolic. Neither is
perfect but “magic incantations” is really a stretch — to be honest, it sounds
like you’re reading with intention of looking for reasons to dislike it.

I started with Mercurial at least a year before Git and found roughly as many
areas where I preferred either one. Having taught a number of people how to
use the basics over the years, I’m highly skeptical of claims that either is a
substantial barrier compared to learning how to use a version control system
and work well with other contributors.

~~~
likpok
I switched to mercurial a couple years back, and generally found it a much
smoother and nicer experience. It can't do anything that git can't do, but the
basic operations felt much better.

A summary of the stuff I liked: histedit feels much more natural than rebase
-i, and I rarely need to look up arguments.

When rebasing, I frequently found that I needed to look up what was what of
the three refs git can take (source, dest and onto).

hg undo, unamend and split take complicated flows in git and make them
trivial.

I don't think I ever got as good an understanding of the hg model as I had
with git, but I had to get that understanding because I screwed up my repo and
wanted to fix it. I've never done that in hg.

~~~
acdha
See, this is a useful comment: it avoids hyperbole and has specific details
people can understand even if they don’t agree with every point.

I have only once had a VCS lose data, but that was amusingly the opposite:
mercurial, before they had a standard rebase-like mechanism, so the only
takeaway I’d draw is that a feature like that needs to be very well tested.

------
ndesaulniers
Back when I worked on Firefox, mozilla-central was an hg (mercurial) repo.

A teammate maintained a plug-in for git to talk to hg servers, called git
cinnibar, IIRC.

Never had to leave the familiarity of git, it was great.

At Google, there's a "git wrapper" for our perforce fork, except nothing at
all like git (git5, a play on p4 I suppose).

Context switching between git and anything else at this point for me is a
considerable waste of my time.

In the same vein, this looks useful for folks more familiar with hg.

~~~
brmgb
> Context switching between git and anything else at this point for me is a
> considerable waste of my time.

My last job used a mix of SVN, Clearquest (with and without UCM) and Git for
different projects. It wasn't that big of a deal. You just need to learn the
concepts if there are new ones and how to use the commands/GUI.

At the end of the day, it's just a version control system. People are far too
invested in their tools.

------
Conan_Kudo
The only problem with this is that pygit2 needs a lot of love. The performance
of pygit2 is kind of weak, and it doesn't even support everything libgit2
supports.

Maybe this will be the kick in the pants to get pygit2 to be better
maintained?

------
epalm
With BitBucket sunsetting hg repos (creation disabled in February 2020, all
repos removed in June 2020), it would be quite timely if this extension
matures in short order.

One can dream, I suppose ;)

------
kalessin
I am excited as well, it would/will be really nice to use the tools or
features that have been developed for both ecosystems in a more seamless way.

------
NilsIRL
Since everyone is talking about what is better about Mercurial compared to
Git.

I would like to know what git does better than mercurial.

~~~
catalogia
I find git conceptually simpler, but honestly git and mercurial are pretty
close to each other. I've been giving some thought to Fossil recently and it
really seems like the industry missed an opportunity to question some
assumptions and biases about what our tools should provide. For instance,
neither mercurial or git contain issue/bug trackers, but Fossil does.

~~~
DaiPlusPlus
> For instance, neither mercurial or git contain issue/bug trackers, but
> Fossil does.

I’m glad git doesn’t. It’s a separate concern and breaks the “do one thing, do
it well” UNIX philiosophy.

People can’t agree on a schema for issues/bug-trackers as it is, and you’ll
have the ISO 9001-compliant folks who feel compelled to have 150 different
hierarchical fields and 20 different issue classes with the Github issue
pragmatists happy with only using non-hierarchical non-namespace tags. You
could accommodate them all by using a schemaless or custom schema support, but
then you’ll have people fighting over how to implement custom schemas, and
then having to get people to work on building that feature.

It would also be inappropriate for security-sensitive issues or other cases
where compartmentalising information is necessary. (And encrypting the data
doesn’t help once the key gets leaked)

If you really want bug-tracking in-repo, you can still do that with a Text-
file tree or Sqlite DB in a separate branch (probably a good idea to have a
separate checkout to avoid expensive `git checkouts` when the entire tree
changes.

------
tootie
If you can't beat em, join em.

------
vnorilo
I've been looking for an easy way of keeping git mirrors of my hg repos, and
this seems like it would be a huge improvement over the previous extension!
Here's to hoping it lands.

------
phillco
And they called it... harmony.

------
sngz
git is like the VHS of version control

