undefined | Better HN

0 pointsCharlieDigital1y ago0 comments

From the blog:

    > When I left Google three years ago I recall they were trying to figure out what to do about either making Git scale, or adopting Mercurial, or what.

It's interesting because I used Mercurial (hg) for close to a decade after coming from Subversion.

Rarely had to consult the docs for weird edge cases and generally operation felt natural and seamless. It was easy to onboard new devs of all experience levels.

I switched to git 5 years back and I still feel lost sometimes and inadvertently end up in detached head state once in a while. Git feels really "unnatural" or "unintuitive" to me in some way that Mercurial never did (I can't put my finger on why because I never gave Mercurial much thought).

0 comments

sunshowers1y ago

You're like most developers! The core problem is that Git's workflow treats branches as the source of truth for what's in the repo, while Mercurial and its progeny (Jujutsu and Sapling) treat individual commits as the source of truth. The latter is vastly simpler, and also (as Jujutsu shows) more powerful.

While working on a stack of changes, you should be able to check out an earlier commit, amend it, and have its descendants be automatically rebased. Of course you should be able to -- this is a natural and straightforward way to think about working on changes, and builds on prior knowledge about how to work with individual commits and how to rebase them onto a newer upstream. Now compare this to git rebase -i.

j / k navigate · click thread line to collapse