6 ms·

Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not ho

by HWR_14 4y ago

Am I the only one sad that Git beat out Mercurial as the industry standard? And am I also the only one who still knows how to do things in Mercurial but not how to take the corresponding action in Git? I mean, they're things I haven't had a reason to do in years, but it has some psychological cost to feel like I'm using a system I'm worse at.

cryptonector 4y ago
I'm not sad. Mercurial is opinionated. It's had to adopt the Git way slowly, grudgingly.
brianwawok 4y ago
I was on the team of a large org doing a POC between the two. Merc did some stuff better, git did more. I am glad git won out overall. I think the only feature Merc had that I cared about was tracking folders as objects.
- fero14041 4y ago
  Mike Bayer, creator of SQLAlchemy ORM in Python, wrote about migrating its repository from Mercurial to Git, in 2013: https://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/ https://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrat... He had some IMHO strong points in favor of Git itself VS Hg, besides GitHub and its huge userbase, which personally convinced me to switch.
- HWR_14 4y ago
  Mind if I ask what Git did better? The main selling point for the difference between them was the Linus, Linux and then the whole community chose Git. The only big difference I recall Git winning on was in third party tooling and Git supporting more than two parents merging.
  - toyg 4y ago
    Git wasn't really winning until GitHub emerged. The game was still open at that point. Once GH had resoundingly beat the competition for "social coding" (like bitbucket and sourceforge), though, it was all over.
    - deleted 4y ago
      [deleted]
  - brianwawok 4y ago
    This was a lot of years.. but things like: 1) We used some super crappy Clearcase version control system. It was easier to layer Git on top, letting us have a VC on top of a VC. I can't remember if it was impossible, or just easier to do in Git. 2) Conflicts did better. We made kind of torture test of merges and put both systems through. Git was able to resolve more out of the box. 3) Speed of operations, I think Git was a bit faster out of the box. None of this was about Github, as it was comparing self hosted HG vs self hoted GIT.
deleted 4y ago
[deleted]
bsder 4y ago
> Am I the only one sad that Git beat out Mercurial as the industry standard? Quibble: Git didn't win. Github won. Git was simply the parasite on the Github host. However, I feel just like you. Mercurial is just so ridiculously easier to explain to people. I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it.
- shikoba 4y ago
  > I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it. That's the problem. Git has a sane UX. The only issue is that a lot of people who doesn't understand it, write silly tutorials where they spread their misconception about it. The real issue is the poor quality of tutorials over the internet that mislead a lot of people.
  - woojoo666 4y ago
    I don't think the UX is that intuitive. If you want to tweak a commit that's not the branch head, you have to rebase the parent of that commit. From a technical standpoint this sort of makes sense, but for a casual user this is not intuitive at all
    - mathstuf 4y ago
      You rebase onto the parent of that commit. The parent doesn't change. Or am I misunderstanding what you're describing here?
      - woojoo666 4y ago
        But the average casual user just wants to modify the commit. There could easily be a higher level command for this, which internally finds the parent and performs the rebase, but instead Git (and even most GUI tools on top) forces you to go the manual route of selecting the parent and initiating a rebase. It's counterintuitive
mathstuf 4y ago
I like the stage way more than not having it. I think Mercurial has it now as some extension, but my fingers know Git and git-hg is the only way I interact with the tool these days. Explicit rename tracking is a mistake though. I think Linus got that one right.

by HWR_14 4y ago

cryptonector 4y ago

I'm not sad. Mercurial is opinionated. It's had to adopt the Git way slowly, grudgingly.

brianwawok 4y ago

I was on the team of a large org doing a POC between the two. Merc did some stuff better, git did more. I am glad git won out overall. I think the only feature Merc had that I cared about was tracking folders as objects.

fero14041 4y ago
Mike Bayer, creator of SQLAlchemy ORM in Python, wrote about migrating its repository from Mercurial to Git, in 2013: https://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrated-to-git/ https://www.sqlalchemy.org/blog/2013/05/25/sqlalchemy-migrat... He had some IMHO strong points in favor of Git itself VS Hg, besides GitHub and its huge userbase, which personally convinced me to switch.
HWR_14 4y ago
Mind if I ask what Git did better? The main selling point for the difference between them was the Linus, Linux and then the whole community chose Git. The only big difference I recall Git winning on was in third party tooling and Git supporting more than two parents merging.
- toyg 4y ago
  Git wasn't really winning until GitHub emerged. The game was still open at that point. Once GH had resoundingly beat the competition for "social coding" (like bitbucket and sourceforge), though, it was all over.
  - deleted 4y ago
    [deleted]
- brianwawok 4y ago
  This was a lot of years.. but things like: 1) We used some super crappy Clearcase version control system. It was easier to layer Git on top, letting us have a VC on top of a VC. I can't remember if it was impossible, or just easier to do in Git. 2) Conflicts did better. We made kind of torture test of merges and put both systems through. Git was able to resolve more out of the box. 3) Speed of operations, I think Git was a bit faster out of the box. None of this was about Github, as it was comparing self hosted HG vs self hoted GIT.

deleted 4y ago

[deleted]

bsder 4y ago

> Am I the only one sad that Git beat out Mercurial as the industry standard? Quibble: Git didn't win. Github won. Git was simply the parasite on the Github host. However, I feel just like you. Mercurial is just so ridiculously easier to explain to people. I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it.

shikoba 4y ago
> I really don't understand what it is about Git that seems to prevent anybody from coming up with a sane UX for it. That's the problem. Git has a sane UX. The only issue is that a lot of people who doesn't understand it, write silly tutorials where they spread their misconception about it. The real issue is the poor quality of tutorials over the internet that mislead a lot of people.
- woojoo666 4y ago
  I don't think the UX is that intuitive. If you want to tweak a commit that's not the branch head, you have to rebase the parent of that commit. From a technical standpoint this sort of makes sense, but for a casual user this is not intuitive at all
  - mathstuf 4y ago
    You rebase onto the parent of that commit. The parent doesn't change. Or am I misunderstanding what you're describing here?
    - woojoo666 4y ago
      But the average casual user just wants to modify the commit. There could easily be a higher level command for this, which internally finds the parent and performs the rebase, but instead Git (and even most GUI tools on top) forces you to go the manual route of selecting the parent and initiating a rebase. It's counterintuitive

mathstuf 4y ago

I like the stage way more than not having it. I think Mercurial has it now as some extension, but my fingers know Git and git-hg is the only way I interact with the tool these days. Explicit rename tracking is a mistake though. I think Linus got that one right.