15 ms·

Mercurial RFC of a new extension to directly operate on Git repositories

141 points by luu 7y ago

theamk 7y ago
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 7y ago
  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 7y ago
    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.)
- irishcoffee 7y ago
  I don’t think hg has the concept of unnamed heads in any sort of acceptable manner. You can have 2 heads with the same branch name, which I suppose is called an “unnamed head” but your team will berate you if you force push an unnamed head. (You can’t push an unnamed head without force. Using force almost always means you shouldn’t do whatever you’re doing) when git encourages using ‘force’ I say a silent prayer
  - sfink 7y ago
    In a way, this is backwards. hg is and has always been totally fine with multiple unnamed heads; git is the one that insists that topological heads have some ref pointing at them. But I agree with your basic point. Unnamed heads in git and unnamed heads in hg are not treated the same, and could be easy for tools to mix up. (I hadn't realized that this was even possible in git??)
tootie 7y ago
If you can't beat em, join em.
yjftsjthsd-h 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      In 5 years from now, will there still be svners?
      - umvi 7y ago
        Maybe not, but "checkout" still conjures up imagery of libraries, where you get permission to use materials. You "checkout" a book in order to read it. So in that sense, it sort of makes sense to "checkout" a branch. But imagine bringing a book to a librarian and saying "hello, I'd like to checkout this book" and the librarian says "ok" and snatches the book from your hands and throws it into a furnace and tells you not to worry because she will order a new copy to be put on the shelf.
phillco 7y ago
And they called it... harmony.
kalessin 7y ago
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.
ndesaulniers 7y ago
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 7y ago
  > 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.
- damnyou 7y ago
  You haven't checked out fig yet? It's an hg frontend for your monorepo and a little birdie tells me that within google it's a lot more popular than git5
- glandium 7y ago
  It's `git-cinnabar`, and it's still maintained, FWIW.
dreamcompiler 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.
deleted 7y ago
[deleted]
NilsIRL 7y ago
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 7y ago
  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 7y ago
    > 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.
- rmgraham 7y ago
  I haven't used hg enough to have an opinion on it, despite several attempts... Problem is I learn bottom up, and I just haven't been able to "think in mercurial" the way I can "think in git". I find it interesting that what git calls a commit is actually a revision (or checkpoint, snapshot, point-in-time) and what mercurial calls a revision is actually a commit (or patch, delta, changeset). I think a lot of people think in terms of patches/changesets and I suspect (still haven't gotten far enough to confirm) hg is a toolbox for managing them in a similar way to how git is a toolbox for manipulating its snapshot based DAG.
epalm 7y ago
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 ;)
Conan_Kudo 7y ago
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?
vnorilo 7y ago
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.
sngz 7y ago
git is like the VHS of version control

141 points by luu 7y ago

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 7y ago
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 7y ago
  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.)
irishcoffee 7y ago
I don’t think hg has the concept of unnamed heads in any sort of acceptable manner. You can have 2 heads with the same branch name, which I suppose is called an “unnamed head” but your team will berate you if you force push an unnamed head. (You can’t push an unnamed head without force. Using force almost always means you shouldn’t do whatever you’re doing) when git encourages using ‘force’ I say a silent prayer
- sfink 7y ago
  In a way, this is backwards. hg is and has always been totally fine with multiple unnamed heads; git is the one that insists that topological heads have some ref pointing at them. But I agree with your basic point. Unnamed heads in git and unnamed heads in hg are not treated the same, and could be easy for tools to mix up. (I hadn't realized that this was even possible in git??)

tootie 7y ago

If you can't beat em, join em.

yjftsjthsd-h 7y ago

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 7y ago
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 7y ago
  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 7y ago
    In 5 years from now, will there still be svners?
    - umvi 7y ago
      Maybe not, but "checkout" still conjures up imagery of libraries, where you get permission to use materials. You "checkout" a book in order to read it. So in that sense, it sort of makes sense to "checkout" a branch. But imagine bringing a book to a librarian and saying "hello, I'd like to checkout this book" and the librarian says "ok" and snatches the book from your hands and throws it into a furnace and tells you not to worry because she will order a new copy to be put on the shelf.

phillco 7y ago

And they called it... harmony.

kalessin 7y ago

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.

ndesaulniers 7y ago

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 7y ago
> 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.
damnyou 7y ago
You haven't checked out fig yet? It's an hg frontend for your monorepo and a little birdie tells me that within google it's a lot more popular than git5
glandium 7y ago
It's `git-cinnabar`, and it's still maintained, FWIW.

dreamcompiler 7y ago

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 7y ago
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 7y ago
  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 7y ago
    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.

deleted 7y ago

[deleted]

NilsIRL 7y ago

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 7y ago
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 7y ago
  > 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.
rmgraham 7y ago
I haven't used hg enough to have an opinion on it, despite several attempts... Problem is I learn bottom up, and I just haven't been able to "think in mercurial" the way I can "think in git". I find it interesting that what git calls a commit is actually a revision (or checkpoint, snapshot, point-in-time) and what mercurial calls a revision is actually a commit (or patch, delta, changeset). I think a lot of people think in terms of patches/changesets and I suspect (still haven't gotten far enough to confirm) hg is a toolbox for managing them in a similar way to how git is a toolbox for manipulating its snapshot based DAG.

epalm 7y ago

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 ;)

Conan_Kudo 7y ago

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?

vnorilo 7y ago

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.

sngz 7y ago

git is like the VHS of version control