4 ms·

Is git really far worse technology than mercurial? I’ve used both for years and to be honest they are pretty similar. What important capabilities does hg have t

by nezi 5mo ago

Is git really far worse technology than mercurial? I’ve used both for years and to be honest they are pretty similar. What important capabilities does hg have that git does not? Maybe you can argue that hg is more ergonomic, but that’s just polish it doesn’t mean the tech is far better…

bsder 5mo ago
> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync on git repos before any operation that is slightly weird knowing that I may put the repo in some state that I cannot easily unwind. I never did that for Subversion. I never did that for Mercurial. I don't do that for Jujutsu. Those are all sane UX. Side note: Thankfully AI is REALLY good at telling you how to un-wedge your git repo. That should tell you everything you need to know about Git UX and why you should avoid Git.
- funimpoded 5mo ago
  You can add everything and commit all at once in git, so you’re technically using staging but it doesn’t feel like it. I stopped using it the first time I committed something I didn’t want to, over a decade ago, haven’t used it again since so I forget the exact invocation, but I think it was just “-a” or something. Before it bit me though yeah, that did seem like a default I’d have preferred. Not any more.
  - imron 5mo ago
    > Not any more. `git add -p` FTW
- JuniperMesos 5mo ago
  I find staging useful even in small projects. I've been deliberately experimenting with jujutsu for the past year or so in various projects, and one of the workflow differences that I noticed most readily with jujutsu was the lack of a staging area. It took me a while to get used to that.
- spacechild1 5mo ago
  > Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the exception?
  - throwaway613746 5mo ago
    So you're just constantly committing untested versions of you work?
    - spacechild1 5mo ago
      No.
      - throwaway613746 5mo ago
        [dead]
  - joombaga 5mo ago
    I'm with you. My current code is a superset of the task I'm trying to accomplish, test code, leftovers from experiments, etc. I often have to break it up into logical chunks that get merged separately. I tried the jj flow and it's just not my thing. Git matches my mental model exactly, but I used it second (after subversion) and in my most formative years as a developer. Maybe there's a universe out there where things worked out differently.
  - fragmede 5mo ago
    > Am I the exception? Supposedly, Meta has the data to support the claim that you (and I) are the outliers here. Staging is confusing to users, especially new ones, which is why jujitsu explicitly doesn't have staging.
    - 5mo ago
- tekacs 5mo ago
  https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj On the off chance that you haven't already had this suggested to you on HN, I would suggest taking a look at JJ. I use it in all my Git-underneath repos with `jj git init --colocate` (You can run that in a git repo and it will hybridize, or in a new folder and it will init and hybridize). It doesn't have the staging concept, treating the working copy as just another commit (@), and to boot it snapshots the state of the tree into @ when you run any jj command, so you can use `jj op log` to see every intermediate state of your working copy at any time. Commit is just `jj commit` with no staging mechanics, or `jj split` to 'split the working copy commits' (commit some, keep the rest in @).
  - bsder 5mo ago
    I'm already a quite happy jj user, but thanks for the recommendation. :)
    - tekacs 5mo ago
      Glad to hear it :)
- tacticus 5mo ago
  Mercurials lack of not permanent branches early on with the bizarre "we have a plugin for that" way of doing it showing up too late to change the decision not to mention the early "just clone it into a new dir" answer before lightweight branching ...
- BobbyTables2 5mo ago
  With “git reflog” and “git reset” or “git checkout” one can undo any series of ill conceived squash/rebase/amend operations. There’s actually no need to rsync the work area in advance. Try doing the same in any other source control system…
- dreamcompiler 5mo ago
  I haven't lost data to git in a long time and I never rsync anything. But it took a long time to get to that point. Git is extremely predictable, but only after you thoroughly understand it. Until then, it seems to surprise you often and every time it happens you think you've lost data. Many times I've had collaborators who said "git ate my files" and I can usually get their files back in a few minutes. This makes them hate git because they cannot use it without having me on call, and they cannot be bothered to learn git thoroughly themselves because it's too damn hard.
  - martinpw 5mo ago
    I've always felt bad about not understanding git better and wanted to dedicate time to learn it properly but never got to it. Finally this is a use case where AI is really good. It has always been able to get me out of trouble when I mess up, and often rescued files I thought I had lost for good. And is always able to rebase for me, normally a place where I flail pathetically. And it's easy to human verify the result before pushing. Honestly this is one area I really like AI - so I can focus on the things I really need to focus on and not spend a bunch of time becoming an expert in things I don't want to be an expert in.
    - xeyownt 5mo ago
      The best recommendation is "Git Internals" (https://github.com/pluralsight/git-internals-pdf https://github.com/pluralsight/git-internals-pdf). It teaches you how git works from the internal, and give you absolute confidence and understanding on how the tool works. I guess it'd take one day of your life to read it, but I think it pays back a lot.
      - dreamcompiler 5mo ago
        This was indeed one of the sources I read to become a git expert. Git is simple and elegant on the inside. Which you'd never believe if you only studied its UI.
- txhwind 5mo ago
  I'm curious on the use of rsync in version control. What's the source and destination?
  - fragmede 5mo ago
    from src/ to src_final_(4)/
  - xeyownt 5mo ago
    Yeah, this is insane. Show a complete lack of understanding on how the tool works. Using rsync on git is like hammering a nail with a hammer, but then use a 10 pound stone to hammer the hammer.
- didibus 5mo ago
  I often want to "save" but not have a comment, and not ready to make it a clean commit that I want a comment on. That's when I stage, then I can see the diff and revert still. But ya, maybe I could adapt to not worrying about having a million commits instead of clean ones at points that make sense with good comments.
  - Mashimo 5mo ago
    You could also commit, and then squash the pull request.
    - Seattle3503 5mo ago
      Does mercurial allow you to re-write history like that?
      - MattJ100 5mo ago
        Yes, Mercurial has a very advanced history editing system via "evolution": https://wiki.mercurial-scm.org/ChangesetEvolution https://wiki.mercurial-scm.org/ChangesetEvolution A good way of thinking about it is that every commit is itself version-controlled, allowing unlimited edits. This even allows two people in an evolve-enabled repo to make changes to history at the same time, and Mercurial will resolve any conflicts. It makes it trivial to commit (and even share) a "WIP" commit which you can later amend/split/whatever. It's different from git where you basically can't edit history after pushing (in Mercurial this only becomes true if you push to a non-evolvution or "publishing" repo, where everything then gets squashed for public consumption).
adjejmxbdjdn 5mo ago
If you think about how much investment has gone into Git, whereas Mercurial has really been developed by a skeleton team, even the fact that they’re similar is indicative that Mercurial may have been better at its core. I haven’t touched mercurial in like 15 years, and from what I remember its UX was superior to what Git provides today. It had an extension system which I don’t remember the full capabilities of so I don’t know if Git has even now matched up to that.
- GuB-42 5mo ago
  Git doesn't have an extension system because it works differently from Mercurial in that regard. Mercurial is more monolithic, and is based on python, writing an extension means writing a bit of python and telling Mercurial to integrate it. Git is more like a loosely connected collection of commands working on the filesystem. It means that extending git is just creating an executable with a particular name in a particular directory. The executable can in turn call other commands, in particular the low level "plumbing", or even work directly with the files in .git. They way they are similar is that they follow the same model: a decentralized system based on a DAG. And speaking of a "skeleton team", git was famously Linus Torvalds 2-week side project, and even though so much development has happened, providing tooling, convenience, performance, portability, etc... at its core, it never changed.

by nezi 5mo ago

bsder 5mo ago

> Is git really far worse technology than mercurial? Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". In addition, Git's UX is hot garbage. I would constantly be doing rsync on git repos before any operation that is slightly weird knowing that I may put the repo in some state that I cannot easily unwind. I never did that for Subversion. I never did that for Mercurial. I don't do that for Jujutsu. Those are all sane UX. Side note: Thankfully AI is REALLY good at telling you how to un-wedge your git repo. That should tell you everything you need to know about Git UX and why you should avoid Git.

funimpoded 5mo ago
You can add everything and commit all at once in git, so you’re technically using staging but it doesn’t feel like it. I stopped using it the first time I committed something I didn’t want to, over a decade ago, haven’t used it again since so I forget the exact invocation, but I think it was just “-a” or something. Before it bit me though yeah, that did seem like a default I’d have preferred. Not any more.
- imron 5mo ago
  > Not any more. `git add -p` FTW
JuniperMesos 5mo ago
I find staging useful even in small projects. I've been deliberately experimenting with jujutsu for the past year or so in various projects, and one of the workflow differences that I noticed most readily with jujutsu was the lack of a staging area. It took me a while to get used to that.
spacechild1 5mo ago
> Most people on small projects just want "checkpoint the current code in my directory and put a comment on it". Interesting, that's definitely not how I use git. My current code is rarely in a shape that can be fully committed. It often contains additional stuff I did on the way (small bug fixes, TODO comments, debug printf statements, etc.) that I don't want in the commit. Very rarely do I type `git add .` Am I the exception?
- throwaway613746 5mo ago
  So you're just constantly committing untested versions of you work?
  - spacechild1 5mo ago
    No.
    - throwaway613746 5mo ago
      [dead]
- joombaga 5mo ago
  I'm with you. My current code is a superset of the task I'm trying to accomplish, test code, leftovers from experiments, etc. I often have to break it up into logical chunks that get merged separately. I tried the jj flow and it's just not my thing. Git matches my mental model exactly, but I used it second (after subversion) and in my most formative years as a developer. Maybe there's a universe out there where things worked out differently.
- fragmede 5mo ago
  > Am I the exception? Supposedly, Meta has the data to support the claim that you (and I) are the outliers here. Staging is confusing to users, especially new ones, which is why jujitsu explicitly doesn't have staging.
  - 5mo ago
tekacs 5mo ago
https://github.com/jj-vcs/jj https://github.com/jj-vcs/jj On the off chance that you haven't already had this suggested to you on HN, I would suggest taking a look at JJ. I use it in all my Git-underneath repos with `jj git init --colocate` (You can run that in a git repo and it will hybridize, or in a new folder and it will init and hybridize). It doesn't have the staging concept, treating the working copy as just another commit (@), and to boot it snapshots the state of the tree into @ when you run any jj command, so you can use `jj op log` to see every intermediate state of your working copy at any time. Commit is just `jj commit` with no staging mechanics, or `jj split` to 'split the working copy commits' (commit some, keep the rest in @).
- bsder 5mo ago
  I'm already a quite happy jj user, but thanks for the recommendation. :)
  - tekacs 5mo ago
    Glad to hear it :)
tacticus 5mo ago
Mercurials lack of not permanent branches early on with the bizarre "we have a plugin for that" way of doing it showing up too late to change the decision not to mention the early "just clone it into a new dir" answer before lightweight branching ...
BobbyTables2 5mo ago
With “git reflog” and “git reset” or “git checkout” one can undo any series of ill conceived squash/rebase/amend operations. There’s actually no need to rsync the work area in advance. Try doing the same in any other source control system…
dreamcompiler 5mo ago
I haven't lost data to git in a long time and I never rsync anything. But it took a long time to get to that point. Git is extremely predictable, but only after you thoroughly understand it. Until then, it seems to surprise you often and every time it happens you think you've lost data. Many times I've had collaborators who said "git ate my files" and I can usually get their files back in a few minutes. This makes them hate git because they cannot use it without having me on call, and they cannot be bothered to learn git thoroughly themselves because it's too damn hard.
- martinpw 5mo ago
  I've always felt bad about not understanding git better and wanted to dedicate time to learn it properly but never got to it. Finally this is a use case where AI is really good. It has always been able to get me out of trouble when I mess up, and often rescued files I thought I had lost for good. And is always able to rebase for me, normally a place where I flail pathetically. And it's easy to human verify the result before pushing. Honestly this is one area I really like AI - so I can focus on the things I really need to focus on and not spend a bunch of time becoming an expert in things I don't want to be an expert in.
  - xeyownt 5mo ago
    The best recommendation is "Git Internals" (https://github.com/pluralsight/git-internals-pdf https://github.com/pluralsight/git-internals-pdf). It teaches you how git works from the internal, and give you absolute confidence and understanding on how the tool works. I guess it'd take one day of your life to read it, but I think it pays back a lot.
    - dreamcompiler 5mo ago
      This was indeed one of the sources I read to become a git expert. Git is simple and elegant on the inside. Which you'd never believe if you only studied its UI.
txhwind 5mo ago
I'm curious on the use of rsync in version control. What's the source and destination?
- fragmede 5mo ago
  from src/ to src_final_(4)/
- xeyownt 5mo ago
  Yeah, this is insane. Show a complete lack of understanding on how the tool works. Using rsync on git is like hammering a nail with a hammer, but then use a 10 pound stone to hammer the hammer.
didibus 5mo ago
I often want to "save" but not have a comment, and not ready to make it a clean commit that I want a comment on. That's when I stage, then I can see the diff and revert still. But ya, maybe I could adapt to not worrying about having a million commits instead of clean ones at points that make sense with good comments.
- Mashimo 5mo ago
  You could also commit, and then squash the pull request.
  - Seattle3503 5mo ago
    Does mercurial allow you to re-write history like that?
    - MattJ100 5mo ago
      Yes, Mercurial has a very advanced history editing system via "evolution": https://wiki.mercurial-scm.org/ChangesetEvolution https://wiki.mercurial-scm.org/ChangesetEvolution A good way of thinking about it is that every commit is itself version-controlled, allowing unlimited edits. This even allows two people in an evolve-enabled repo to make changes to history at the same time, and Mercurial will resolve any conflicts. It makes it trivial to commit (and even share) a "WIP" commit which you can later amend/split/whatever. It's different from git where you basically can't edit history after pushing (in Mercurial this only becomes true if you push to a non-evolvution or "publishing" repo, where everything then gets squashed for public consumption).

adjejmxbdjdn 5mo ago

If you think about how much investment has gone into Git, whereas Mercurial has really been developed by a skeleton team, even the fact that they’re similar is indicative that Mercurial may have been better at its core. I haven’t touched mercurial in like 15 years, and from what I remember its UX was superior to what Git provides today. It had an extension system which I don’t remember the full capabilities of so I don’t know if Git has even now matched up to that.

GuB-42 5mo ago
Git doesn't have an extension system because it works differently from Mercurial in that regard. Mercurial is more monolithic, and is based on python, writing an extension means writing a bit of python and telling Mercurial to integrate it. Git is more like a loosely connected collection of commands working on the filesystem. It means that extending git is just creating an executable with a particular name in a particular directory. The executable can in turn call other commands, in particular the low level "plumbing", or even work directly with the files in .git. They way they are similar is that they follow the same model: a decentralized system based on a DAG. And speaking of a "skeleton team", git was famously Linus Torvalds 2-week side project, and even though so much development has happened, providing tooling, convenience, performance, portability, etc... at its core, it never changed.