Hacker News Reader

Comment by fer | Hacker News Reader

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".

View on HN

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.

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

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.

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

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

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?

Why undo it? Just merge them. Undoing isn't difficult either, but I've never understood this obsession with clean repository history.

Your comment describes the obsession perfectly. A clean repository history. It helps with things like... History.

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.

> 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?

> 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 show you what you actually committed and don't allow you to do stupid things that might corrupt your repository, which is what matters.

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

"Working code" and important milestones in the state of the tree are tracked by tags, bookmarks and other features depending on what source control system you use. The state of the tree at every single commit point is an irrelevant detail.

> No DVCS can prevent someone from designing what their commit history looks like.

Correct, and they shouldn't encourage you to waste your time trying to do so, and so shouldn't make it easy either.

> Hehehe you’ve never had to look at the history then, I assume? You’ve never had to bisect?

I've been doing it for over 20 years, first with subversion, then Mercurial. Never had any issues figuring out what was going on. Taking a few extra minutes here and there to scan through such changes is nothing compared to trying to fixing a repository corruption, which is something I recently had to deal with.

Everything you describe can be handled by 1) a better commit log history tool and more importantly, 2) better development practices that requires adding proper comments and tickets to code and commits that describe context and rationale for changes. Opening up history to revisions is a sledgehammer trying to solve a bunch of distinct problems that require better solutions.

> Doesn’t that prove that a clean view of history does help, and is something a lot of people want?

Of course it helps, sometimes. As I've described above, that doesn't mean you should introduce a sledgehammer for the occasional pain point that can be addressed by other, arguably better means.

> They show you what you actually committed and don't allow you to do stupid things that might corrupt your repository, which is what matters.

Who cares what you actually committed on a per-commit basis, especially when fixing things that were mistakes in the first commit, and would have been committed as part of the first commit with more planning and/or no innocuous accidents? Who needs to preserve the already arbitrary order of commit commands, and why? I’ve never heard a compelling and real-world reason to need this, nor any popular workflow that this idea establishes or improves.

And what repo corruption are you talking about? I don’t know about you, but one thing people espousing this ‘what actually happened’ philosophy and trying to trash-talk git tend to deliberately overlook is that git commit histories are immutable, and rebase only produces a new commit lineage, with an in-tact backup of the previous lineage surviving anything you do. It’s not possible for the history to be irrecoverably corrupted, unless you’re unfairly including bugs or hardware failures. Recovering from rebase mistakes is simply a matter of learning where the undo knobs are, and ultimately they are pretty easy to use, it’s no more work and no different outcome than learning how to groom the presentation history of Hg or other systems.

> especially when fixing things that were mistakes in the first commit, and would have been committed as part of the first commit with more planning and/or no innocuous accidents?

Follow-up fixes reveal important nuance and implicit assumptions that shouldn't be erased.

As for your other claims of "simply" and "easy", you need only peruse this thread that covers plenty of rebase stories losing entire commit histories and requiring redoes of weeks worth of work to see either it is neither easy or simple.

Edit: See also this point by point breakdown: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

> Follow-up fixes reveal important nuance and implicit assumptions that shouldn’t be erased

That’s definitely not always true. In my experience that’s a small minority of cases, and when it happens, I keep the important nuance commits and don’t squash them. Nobody is forcing you to squash, it’s an option for the (many) fix up commits that were pure accidental oversight and have no nuance that needs to be preserved.

I’ve seen lots of people claim they lost work, because they freaked out or gave up without slowing down to think carefully. The reason is because they didn’t learn how git actually works, and never learned the undo buttons. I’m well aware that git’s CLI is intimidating and unintuitive, but one thing it does not do is corrupt your repo for you. That’s effectively a blaming excuse for not having learned how it works.

Replying to your later edit. I’m aware of Fossil’s language, which is pretty hyperbolic. It’s largely a straw-man argument, because Fossil devs have presumed to state the intentions of git devs and git users, and they jump to a bad-faith conclusion in order to state their opinion that Fossil is better than git. Keep in mind the Fossil pages are marketing, and they are comparing themselves to the competition (git) by trying to paint git in a negative light, with prejudice. They wish they had the market share that git does, and so you should trust that language just as much as you trust a Pepsi TV commercial. Dr. Hipp has stated on HN his belief that editing code history should be considered a criminal activity, without sufficient justification for such an extreme and unique point of view.

BTW I have a ton of respect for SQLite and Dr. Hipp’s work. I love the way he has talked about testing. Nonetheless, I’m very much not a fan of their trash-talking of git that intentionally ignores the context, guidance, and real-world usage of rebase. The irony of them saying that git rebase is “dishonest” is that they themselves are being intentionally dishonest about how they talk about git, and I find it very off-putting and hypocritical, to be as polite as possible.

Reply on news.ycombinator.com