I hope one day Pijul[1] will become more common, as the more advanced alternative to git.
I kind of killed Mercurial at Mozilla
161–170 of 250 posts
Re: I kind of killed Mercurial at Mozilla
#162I've heard this point of view many times, but cannot find an extensive explanation of it. Could anyone elaborate on the issue with the GitHub review UI/UX? > I hate the GitHub review UI with a passion. At least, right now, GitHub PRs are not a viable option for Mozilla [...] the more general shortcomings in the review UI.
I know people who express similar feelings. Usually it is shorthand for "I would prefer stacked diffs" or similar. Two blog posts I've seen people point at: * https://mitchellh.com/writing/github-changesets * https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/
What are these people talking about? What's the difference between "stacked diffs" and just adding commits to a branch? Who cares if the branch is called "master" or not? You could also force push updated commits (e.g. after fixup and rebase etc) and tools like Gitlab and GitHub can show you the diff between versions (or "changesets", as they call them). Gitlab at least makes it pretty clear when a change has been made and the order things were done in. Pretty sure GitHub does too.
Re: I kind of killed Mercurial at Mozilla
#163Earlier quoted context omitted.
And Google has been putting much of their investment behind jj. One other interesting thing I've noticed, mercurial has stopped building windows standalone releases. It's been that way for around 9 months.
What’s jj?
https://github.com/martinvonz/jj a more recent version control system.
Re: I kind of killed Mercurial at Mozilla
#164I liked the thorough article, but my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). I think the short version is: they made `git-cinnabar`, which is a git-to-hg translator, to help git users interact with the Mozilla repos. ---- One contribution I can make: > For reasons I don't know, Mozilla decided to use separate Mercurial repositories as "branches". O…
> Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (:
Same here. It is one of the minor tragedies that git won the popularity contest when mercurial is so much more pleasant.
Re: I kind of killed Mercurial at Mozilla
#165I don't understand why so many people seem to dislike git. But maybe in actuality it is not many people, as usually people who are discontent are the loudest. I used Mercurial in the past for a bit, and it was fine. But for me it doesn't seem to have any huge advantages over git, if any. And after so many years of experience using git, I know what workflows work well, how to resolve merge conflicts, how to revert to…
Essentially, the problem with git is - it is a tool that is simple in its internals, but with a complex/confusing UI. The only way for someone to feel somewhat in comfortable with git is to have a good conceptual model for how it works internally. Once you have that mental model, you feel like a magician with git, but for beginners, it is a source of endless confusion and fear.
GIT is a tool. Like a swiss army knife, it looks tricky and you need some experience to master all what it provides. But you never actually need everything and, surely, you should also shy away from features if you do not really need them. In this respect GIT is a bit like Perl or C++. You have to apply some discipline to avoid unnecessary complexity. Personally, I have never used GIT's "octopus" merge support but I am sure in some situation it may well be a useful feature to have. So I respect that while scratching my head. ;)
Those are basically all commands I am really ever using:
git status
git add
git rm
git commit
git branch
git checkout -t -b ...
git merge
Learn those and you'll mostly good to go.
Sure, I could to rebase my branches all day and make sure my version history looks "pretty" but I find obsessing with the commit history is a major source of complexity people face when using git. Another usual source of confusion is the branching model. However, that totally depends on your organization. GIT is flexible enough to support all kinds of weird development processes but if it comes over as complicated then don't put the blame on the tool but on its users.
Re: I kind of killed Mercurial at Mozilla
#166Re: I kind of killed Mercurial at Mozilla
#167Earlier quoted context omitted.
> It's just the network effect It's almost like qwerty vs dvorak in that regard, except git and mercurial were contemporaries. Mercurial isn't quite good enough to displace git, and git has Linus as a promoter which was all it needed to be the leader. That said, I agree that the network effect of having just one is more valuable than mercurial's ergonomics (which could still use a good branch story).
Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage). There’s a meme that Git is hard to use but I think it’s conflating…
> There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool.
Anecdote follows!
I originally started with cvs, and then later, svn. I struggled when git came along, the workflow felt super cumbersome and I kept tripping over the 3 stage process (working directory, staged for commit, and committed), compared to the 2 stage process for already-tracked files in cvs and svn.
After several years, I still never got used to it, and kept having to google when I’d run into random weird issues, having accidentally gotten my repo into a state that had strayed from the basic happy path. Then I started using hg at work, and life got a whole lot easier.
I still haven’t migrated my personal repos off git into hg, mostly because I haven’t (looked for, or) found an hg equivalent of gitea that I can self host, but from my personal experience, day to day usage of git is way harder than day to day usage of hg.
Then again, it helps that I learned hg on the company dime, instead of on my own time.
Re: I kind of killed Mercurial at Mozilla
#168Earlier quoted context omitted.
FB/Meta replaced Mercurial with Sapling which is git-compatible: https://engineering.fb.com/2022/11/15/open-source/sapling-so... Mercurial is over.
And Google has been putting much of their investment behind jj. One other interesting thing I've noticed, mercurial has stopped building windows standalone releases. It's been that way for around 9 months.
Have they? It seems there's only one Google employee working on it.
Re: I kind of killed Mercurial at Mozilla
#169I liked the thorough article, but my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). I think the short version is: they made `git-cinnabar`, which is a git-to-hg translator, to help git users interact with the Mozilla repos. ---- One contribution I can make: > For reasons I don't know, Mozilla decided to use separate Mercurial repositories as "branches". O…
Author here. > my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). Fair point. I came up with the title first. Then as the content grew large and diluted the essence of the title, I reconsidered, but ended up sticking to it as a shameless clickbait. > Originally, separate clones was the recommended way to do "topic branches" in Mercurial (not to be confused…
Tracking down preed, JST, joduin, bsmedberg, etc might turn up stories.
Some of it is captured by preed in https://soberbuildengineer.com/blog/2006/11/version-control-... and announcing hg in https://soberbuildengineer.com/blog/2007/04/version-control-...
JST post on bzr vs hg perf, https://web.archive.org/web/20070219012211/http://weblogs.mo...
Re: I kind of killed Mercurial at Mozilla
#170I liked the thorough article, but my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title). I think the short version is: they made `git-cinnabar`, which is a git-to-hg translator, to help git users interact with the Mozilla repos. ---- One contribution I can make: > For reasons I don't know, Mozilla decided to use separate Mercurial repositories as "branches". O…
> Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (: One of my favorite stories happened three or four jobs ago... at this job I kept a giant whiteboard that I had swiped from a conf room, behind my cubicle. And whenever anybody asked questions we put it up on the board. We were an SVN shop and someone had asked how Git worked and I was like "do you want me to explain G…
I miss Mercurial, thankfully ToirtoiseGit is similar experience to the Mercurial and SVN clients, and like a large majority I just fix git issues by cloning from scratch as the famous xkcd comic.