Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

Post reply on HN
Print view View original

201–210 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#201

Post by iggldiggl »

zarzavat wrote: post #142
BrenBarn wrote: post #140

I hate to see more and more people switching from Mercurial to Git. The way to overcome the "network effects" is exactly for large projects like Mozilla to stand tall and say clearly that they are going to use Mercurial because it is better and git is worse . Of course, I shouldn't really expect such from Mozilla given all the other dubious actions they've taken over time.

Git won a long long time ago. Most people’s first VCS is now git. Mercurial is a lot better than SVN so it was able to pick up users back when SVN was dominant, but it’s not really better or worse than git it’s just down to taste. When you consider the network effects and switching costs it’s hard to convince anyone that mercurial is worth learning.

I initially picked up Git because that was the cool/recommended thing to do. Then I started contributing to Firefox and at that time the story for using Git with Firefox's Mercurial repository was much more cumbersome, so I gave up and started using Mercurial instead. Over time, Mercurial has grown on me and these days I actually prefer it over Git.

Re: I kind of killed Mercurial at Mozilla

#202

Post by guenthert »

acdha wrote: post #117
dehrmann wrote: post #98

Earlier 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…

> Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage.

Count yourself lucky then. Git was well known for losing data, so much, that it was featured at xkcd [1]. Well, perhaps not the tool itself, but it's user interface was (more than it is now perhaps) so awkward that users often got it wrong. If you don't make that back-up, you might not even know how much you've lost.

[1] https://xkcd.com/1597/

Re: I kind of killed Mercurial at Mozilla

#203

Post by seanw444 »

grey_earthling wrote: post #199

Switching to Git makes sense, but choosing GitHub is diametrically opposed to what Mozilla claim their principles are — specifically principle 6 of the Mozilla Manifesto: “The effectiveness of the internet as a public resource depends upon interoperability (protocols, data formats, content), innovation and decentralised participation worldwide.” => https://www.mozilla.org/en-GB/about/manifesto/ In future it won't be…

> They're an untrustworthy upstream.

All I needed to come to this conclusion was the abandonment of interesting (and necessary) projects like Servo, and the continual increase of superiors' salaries.

Re: I kind of killed Mercurial at Mozilla

#204

Post by guenthert »

G3rn0ti wrote: post #165
alex_smart wrote: post #133

Earlier quoted context omitted.

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…

I find it interesting how many tutorials praise the simplicity of git while simultaneously assume nothing goes ever wrong. It's when you have to pull the main branch into the feature branch you're working on (because you sure don't want to do the big merge in a few weeks when you're done, not the least, because you don't even know whether you're still there to do it), but aren't ready to commit all changes made yet, when Murphy assures that there are conflicts. Then you have to do the stash/pop dance and since you manage to not fix all conflicts, the stash wasn't dropped, which you do manually and you just lost some changes. Then you wished you'd done a back-up before the pull ...

Sure, if you always commit your changes before pulling, then you won't need the stash and (even old CVS documentation reminded us that a VCS tool cannot replace communication) if there are no unrelated changes in the files you're working on, there won't be conflicts, but that just aren't realistic assumptions.

Re: I kind of killed Mercurial at Mozilla

#205

Post by seanw444 »

knallfrosch wrote: post #196
G3rn0ti wrote: post #165

Earlier quoted context omitted.

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…

Although I understand all these commands and can use them, it's a typical Linux tool. Sure, if you understand the internals you can use the tools and the horrendous GUIs that are nothing more than a thin layer of paint. But a truly user-centric tool would actually help you with something like "I want to work on a new Feature A" "I want to continue working on Feature B" "I want my changes in the software/product" "I w…

It's a low-level tool. Imagine writing code with Microsoft Word. There are layers on top of Git that give you more of what you're looking for.

- https://github.com/extrawurst/gitui

- https://github.com/jesseduffield/lazygit

- https://magit.vc/

Re: I kind of killed Mercurial at Mozilla

#206

Post by cmrdporcupine »

bvrmn wrote: post #152
bigstrat2003 wrote: post #116

Earlier quoted context omitted.

Exactly this. To be perfectly honest, the git CLI is so bad that I would take pretty much anything over git. I would prefer SVN over git, despite that product being older and with less functionality, just because it's at least easy to use. I learned and use git because that's just how the industry has moved, and I'm pragmatic enough to just roll with it. But good Lord, the UI is a case study in "programmers shouldn't…

> I would prefer SVN over git Yes SVN has so much better CLI especially for things like * merging * history navigation * searching commit messages, filenames and file content * bisecting I'm filled with joy remembering good old SVN days and how my life was a way easier.

Yeah, SVN was terrible. Its chief advantage was it was just less terrible than CVS and carried roughly the same workflow, so wasn't unfamiliar to people. It was basically CVS with atomic commits and a better interface and transport layer. You could drop SVN into a CVS shop without ruffling many feathers -- and back then I found most people were quite resistant to "novelty" in revision control systems, so SVN fit into that.

I don't think there's anything intrinsically wrong with a centralized revision control system. I used Piper/CitC at Google for years and it could be ... tolerable. Many people just end up using git this way anyways.

But SVN shipped with garbage merge-on-merge support, and that was the deal-breaker for me.

Re: I kind of killed Mercurial at Mozilla

#208

Post by ilostmymangoman »

culebron21 wrote: post #173
wsc981 wrote: post #108

I 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…

Despite having 14 years of experience with Git, I still can't use it without Stackoverflow for any non-daily task. And I've read the internals back in 2008 and understand this, but it doesn't make it any clear how merges, conflict resolution, or amendments to commits work. Absolutely confusing. In Mecrurial a lot more stuff is clear and easy to remember. Example: I tried rebasing or merging, and got merge conflicts.…

When conflicts occur when performing rebase, git prints out the following: ``` hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm ", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". ```

The options on how to proceed seem pretty clear to me.

Re: I kind of killed Mercurial at Mozilla

#209

Post by G3rn0ti »

guenthert wrote: post #204
G3rn0ti wrote: post #165

Earlier quoted context omitted.

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…

I find it interesting how many tutorials praise the simplicity of git while simultaneously assume nothing goes ever wrong. It's when you have to pull the main branch into the feature branch you're working on (because you sure don't want to do the big merge in a few weeks when you're done, not the least, because you don't even know whether you're still there to do it), but aren't ready to commit all changes made yet,…

Sounds like you should commit more often inside you topic branches.

In case you are talking about merge conflicts: That's the nature of distributed development other people might trump on places you are currently working on.

I guess there are more intelligent merge strategies. But GIT gives you a list of files that need a manual merge and you have to look into them one by one. GIT even tells you what to do in this case.

Re: I kind of killed Mercurial at Mozilla

#210

Post by aseipp »

rbehrends wrote: post #194
wsc981 wrote: post #108

I 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…

I could go into some detail here why Git is the harder to use system of the two, but I think that would miss the bigger point. IMO, the larger and longer-term problem is that (open source) version control systems seem to be mostly stuck in the early aughts. This may sound provocative, but in principle, Git and Mercurial don't offer much that wasn't already part of Monotone. Meta/Facebook has really been the only acto…

> why don't version control systems (especially ones that can change history) have undo/redo functionality out of the box?

It's true. And Jujutsu has undo functionality out of the box, too. It's not just Sapling. :) https://github.com/martinvonz/jj

Post reply on HN