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

231–240 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#231

Post by Fatnino »

happymellon wrote: post #227
crdrost wrote: post #90

Earlier quoted context omitted.

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

There are plenty of nice GUIs for got as well. TortoiseGit works, Fork is pretty good but it's a shame that GitKraken is so expensive.

You have to pay to use hg in gitkraken?

I use it for git all the time for free.

I liked hg a lot when I worked at a place that used it but I've since just sortof defaulted to git for my own stuff since that what everyone seems to be using.

Re: I kind of killed Mercurial at Mozilla

#232

Post by happymellon »

Fatnino wrote: post #231
happymellon wrote: post #227

Earlier quoted context omitted.

There are plenty of nice GUIs for got as well. TortoiseGit works, Fork is pretty good but it's a shame that GitKraken is so expensive.

You have to pay to use hg in gitkraken? I use it for git all the time for free. I liked hg a lot when I worked at a place that used it but I've since just sortof defaulted to git for my own stuff since that what everyone seems to be using.

Last time I tried GitKraken it did not like anything vaguely private (with git) without trying to charge you a monthly subscription.

I pay for Jetbrains, so I'm not adverse to spending money on software, but I don't like subscription software like this.

Re: I kind of killed Mercurial at Mozilla

#233

Post by jamienicol »

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…

> In future it won't be possible to contribute to Firefox without a Microsoft account

What makes you think that?

Re: I kind of killed Mercurial at Mozilla

#234

Post by stonewhite »

alex_smart wrote: post #133
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…

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.

I think the idiosyncratic command names are rooted in the fact that git is designed as a peer to peer distributed system as opposed to how it is generally used right now, the server/client workflow. Github even follows and adds to this tradition with the always weird sounding "pull request", since the pull request is normally a mail to a mailgroup with the description of the changes and an actual request to pull that person's changes to the maintainers local repositories.

I'm not sure what is currently being done at developing git, but adapting/creating some porcelain commands accommodating a more centralized workflow even mainly on a semantic level could help with the UX friction.

Also, the obligatory joke "git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space"

Re: I kind of killed Mercurial at Mozilla

#235

Post by acdha »

guenthert wrote: post #228
meindnoch wrote: post #214

Earlier quoted context omitted.

>Why does 'pull' imply 'checkout'? ??? It doesn't.

It sadly clobbers your working tree. Not calling that checkout doesn't make it any better. Nothing other than checkout ought to change the working tree -- is that too much to ask?

How does it clobber your working tree? You’ll get an error if there are any conflicts.

Re: I kind of killed Mercurial at Mozilla

#236

Post by acdha »

chx wrote: post #219
acdha wrote: post #200

Earlier quoted context omitted.

Sure, but most of those are things you rarely need and it’s not like Mercurial was an AI which always knew what you meant - anyone who ever tried to explain merge-queues to someone else knows that some concepts are just harder than others.

No need for hard concepts. I am talking of things like "opsie, I don't want to commit this yet" (git reset) and "destroy all my work" (git reset --hard) being a command line switch apart. That's just wrong. That's so wrong I keep git reset --hard safety net around, in fact. https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29

Kind of like how “hg update” becomes “destroy all my work” with -C? At some point you do need to learn what things to be careful about. Git’s reflog will avoid most forms of data loss but uncommitted/staged changes are a harder problem than it might seem.

Re: I kind of killed Mercurial at Mozilla

#237

Post by sys_64738 »

yjftsjthsd-h wrote: post #229
sys_64738 wrote: post #56

Solaris source control moved to Mercurial so if you want to know if it scales then the answer is yes. I miss SCCS.

Didn't Sun have Gatekeepers carefully controlling what commits were made to any given gate, thereby ensuring that the actual source control would never be the limiting factor in scaling things out? (Don't get me wrong, I love mercurial, I just don't think this particular example demonstrates much because it always sounded like they'd sidestepped the issue.)

Yes, any putback to ON required an advocate to vouch for your change. Basically a neck to wring when things go wrong. You generally had me chance so don’t F. Up.

Re: I kind of killed Mercurial at Mozilla

#238

Post by guenthert »

acdha wrote: post #235
guenthert wrote: post #228

Earlier quoted context omitted.

It sadly clobbers your working tree. Not calling that checkout doesn't make it any better. Nothing other than checkout ought to change the working tree -- is that too much to ask?

How does it clobber your working tree? You’ll get an error if there are any conflicts.

Yes, sorry, that was poor writing style. Git does indeed warn you that it would clobber your working tree and suggests that you do it in its behalf (the stash/pop dance).

Why is the user exposed to that? If git needs those files checked out for the merge, does it really have to be in the working tree? Why not in a hidden, ephemeral subdirectory? Leave my working tree alone, I say!

Re: I kind of killed Mercurial at Mozilla

#240

Post by acdha »

guenthert wrote: post #202
acdha wrote: post #117

Earlier quoted context omitted.

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

That’s not really what that xkcd is about but that was kind of my point: it’s a long-running joke but it’s not really true – in reality Git makes it really hard to lose data, and most of the time when people say they lost data what they really meant was that they had a sloppy merge and needed help using reflog to retry it.

I’ve worked in modest sized teams within a larger organization (roughly a hundred developers) and have often been the person people ask for help when something goes wrong; most of our teams went from CVS / Source Safe to Subversion, and then Mercurial to Git, and the big step was really the switch to a distributed system - moving from Hg was largely a non-issue (things got faster, we liked GitLab more for other reasons). The only time Hg lost data was back in the era when rebase was an extension, so it wasn’t the core system’s fault but it was a source of friction.

Post reply on HN