5 ms·

Disclaimer: I haven't touched hg in nearly a decade. hg has (had?) a sane CLI that blows (blew?) git out of the water. I like the power of git, but it either

by fer 3y ago

Disclaimer: I haven't touched hg in nearly a decade. hg has (had?) a sane CLI that blows (blew?) git out of the water. I like the power of git, but it either needs external tooling to prevent people from shooting the team in the foot, or relatively thorough study by everyone using it. In practice, for git, most of the time you need some software to protect people from messing up repositories and history (gitlab, github, etc, which honestly you're gonna use anyway), while hg on its own protects you out of the box from most mistakes. All FAANGs I'm familiar with use git, but there are some serious handrails and straps on what you can do. On smaller companies I had so many arguments about rebasing public branches that it's not even funny. For a while I had in the back of my head to create a hg clone that was a wrapper around git, in a way that it'd allow hg-style workflows and protections, while having a faster and more well-known "backend".

Ygg2 3y ago
If hg cli was butt raving mad, it would still be considered "saner" than git. If git was an equivalent modern appliance, it would be against the Geneva convention. I give Git this, it's a bit faster.
- otabdeveloper4 3y ago
  Git is not opinionated and doesn't care about your workflow, which is why it won in the end. (The downside is that, yes, it's ultimately just a collection of tools, not a "framework" for doing software.)
  - Ygg2 3y ago
    Non-opinionated is not an excuse. It's CLI is an unlearnable mess ( ours vs theirs). I've got 10 years in it and it still bites me in the ass.
    - jahav 3y ago
      Maybe, but normal developer interracts with sane parts. Honestly, the biggest problem with git is sane environment for merge conflicts and that is out of scope of git CLI. In most cases, imposing rule for small PRs/feature branches will solve it. git add, git commit, git log, git blame, git push, git rebase -i --onto. That is 95+% of what developers use (maybe an option here or there, like -m or --amend). Merges are done on CI after it passes. There are a lot of arcane parts and switches. git-send-email is likely used a lot on kernel development, but very rarely in the rest of the world. > I've got 10 years in it and it still bites me in the ass. Can you give some examples? I had some problems in the beginnings, but it was because i tried to be "smart". After I embraced KISS, everything works nicely. As long as I keep "public" branches protected, any splash zone is very small and at worst, just redo it(synergy with small PRs).
Pesthuf 3y ago
When using hg, I often accidentally created multiple heads for a branch and I remember that being really annoying and unintuitive to undo.
- fer 3y ago
  I haven't touched it in a while, but AFAIK multiple heads in a branch only happens when you commit twice against the same changeset in the branch. I don't see how this can happen accidentally. Either way you want to merge them back under a single head (a normal 'hg merge') or remove the spurious head ('hg strip'). Maybe it was more complicated at the beginning?
- naasking 3y ago
  Why undo it? Just merge them. Undoing isn't difficult either, but I've never understood this obsession with clean repository history.
  - Krutonium 3y ago
    Your comment describes the obsession perfectly. A clean repository history. It helps with things like... History.
    - naasking 3y ago
      Except then it's not a history of what actually happened, and revising it to make it look "clean" doesn't actually help with anything.
      - dahart 3y ago
        > Except then it’s not a history of what actually happened? What do you mean? Hg and Fossil don’t capture what “actually happened” either, they don’t show you stuff you typed and deleted before committing. They don’t save the compile errors you had or what you tested and changed. They don’t save what you said to your coworkers about their code because they were afraid to set their changes in stone or make a mess. They don’t prevent anyone from putting things into the commit log in a different order than they “actually happened”, and they can’t: these are systems that record only what you tell them. What problem, exactly, does trying to capture ‘what actually happened’ help solve? I don’t understand this obsession with what “actually happened”, as if there’s something critical about auditing keystrokes, as if the working code and the state of the tree are secondary. No DVCS can prevent someone from designing what their commit history looks like. In the mean time, the idea that you shouldn’t be able to edit or change anything locally before showing it to other people seems like a negative force against the basic safety net that a version control system needs to provide. (And no existing DVCS actually prevents rewriting history anyway, they just claim to have preferences and they offer commands to rewrite history that have other names and say honor system, you shouldn’t use them very often.) > revising it to make it look “clean” doesn’t actually help with anything. Hehehe you’ve never had to look at the history then, I assume? You’ve never had to bisect? You don’t care if people interleave different topics in their branches, or make lots of 1-line fixup commits all over the place? You don’t care about how long it takes to find out who changed something, or whether you have to sift through a mountain of garbage to find it? Don’t the DVCSs that have the ‘history is sacred’ dogma also have tools to make presenting and viewing history less noisy than the so-called ‘what actually happened’ commit log? Doesn’t that prove that a clean view of history does help, and is something a lot of people want?

by fer 3y ago

Ygg2 3y ago

If hg cli was butt raving mad, it would still be considered "saner" than git. If git was an equivalent modern appliance, it would be against the Geneva convention. I give Git this, it's a bit faster.

otabdeveloper4 3y ago
Git is not opinionated and doesn't care about your workflow, which is why it won in the end. (The downside is that, yes, it's ultimately just a collection of tools, not a "framework" for doing software.)
- Ygg2 3y ago
  Non-opinionated is not an excuse. It's CLI is an unlearnable mess ( ours vs theirs). I've got 10 years in it and it still bites me in the ass.
  - jahav 3y ago
    Maybe, but normal developer interracts with sane parts. Honestly, the biggest problem with git is sane environment for merge conflicts and that is out of scope of git CLI. In most cases, imposing rule for small PRs/feature branches will solve it. git add, git commit, git log, git blame, git push, git rebase -i --onto. That is 95+% of what developers use (maybe an option here or there, like -m or --amend). Merges are done on CI after it passes. There are a lot of arcane parts and switches. git-send-email is likely used a lot on kernel development, but very rarely in the rest of the world. > I've got 10 years in it and it still bites me in the ass. Can you give some examples? I had some problems in the beginnings, but it was because i tried to be "smart". After I embraced KISS, everything works nicely. As long as I keep "public" branches protected, any splash zone is very small and at worst, just redo it(synergy with small PRs).

Pesthuf 3y ago

When using hg, I often accidentally created multiple heads for a branch and I remember that being really annoying and unintuitive to undo.

fer 3y ago
I haven't touched it in a while, but AFAIK multiple heads in a branch only happens when you commit twice against the same changeset in the branch. I don't see how this can happen accidentally. Either way you want to merge them back under a single head (a normal 'hg merge') or remove the spurious head ('hg strip'). Maybe it was more complicated at the beginning?
naasking 3y ago
Why undo it? Just merge them. Undoing isn't difficult either, but I've never understood this obsession with clean repository history.
- Krutonium 3y ago
  Your comment describes the obsession perfectly. A clean repository history. It helps with things like... History.
  - naasking 3y ago
    Except then it's not a history of what actually happened, and revising it to make it look "clean" doesn't actually help with anything.
    - dahart 3y ago
      > Except then it’s not a history of what actually happened? What do you mean? Hg and Fossil don’t capture what “actually happened” either, they don’t show you stuff you typed and deleted before committing. They don’t save the compile errors you had or what you tested and changed. They don’t save what you said to your coworkers about their code because they were afraid to set their changes in stone or make a mess. They don’t prevent anyone from putting things into the commit log in a different order than they “actually happened”, and they can’t: these are systems that record only what you tell them. What problem, exactly, does trying to capture ‘what actually happened’ help solve? I don’t understand this obsession with what “actually happened”, as if there’s something critical about auditing keystrokes, as if the working code and the state of the tree are secondary. No DVCS can prevent someone from designing what their commit history looks like. In the mean time, the idea that you shouldn’t be able to edit or change anything locally before showing it to other people seems like a negative force against the basic safety net that a version control system needs to provide. (And no existing DVCS actually prevents rewriting history anyway, they just claim to have preferences and they offer commands to rewrite history that have other names and say honor system, you shouldn’t use them very often.) > revising it to make it look “clean” doesn’t actually help with anything. Hehehe you’ve never had to look at the history then, I assume? You’ve never had to bisect? You don’t care if people interleave different topics in their branches, or make lots of 1-line fixup commits all over the place? You don’t care about how long it takes to find out who changed something, or whether you have to sift through a mountain of garbage to find it? Don’t the DVCSs that have the ‘history is sacred’ dogma also have tools to make presenting and viewing history less noisy than the so-called ‘what actually happened’ commit log? Doesn’t that prove that a clean view of history does help, and is something a lot of people want?