Live data from Hacker News

Ask HN: Google/FB engineers, Do you like Mercurial?

news.ycombinator.com

31–40 of 59 posts

Re: Ask HN: Google/FB engineers, Do you like Mercurial?

#31
post #10
post #5

Earlier quoted context omitted.

I don't know about Google, but I believe Facebook keeps all of its code in one gigantic Mercurial repository.

Not exactly "all", but certainly the mother load.

Mother lode, the central, most valuable vein of buried gold.

Re: Ask HN: Google/FB engineers, Do you like Mercurial?

#32
post #7

Earlier quoted context omitted.

Why would you rewrite history? Don't be ashamed.

Rebase is awesome. Here's an example. http://michaeldehaan.net/post/116465000577/understanding-whe...

Some of the arguments against merging made in this article seem a little strange, for example saying "If folks on topic branches rebase, there will not be any conflicts on merge" after previously stating "It’s also a great idea to rebase periodically - several times a day", as there would also be no merge conflicts if the branch was merged in periodically as well. If merge commits are so abhorrent, just alias git log to git log --no-merges

Re: Ask HN: Google/FB engineers, Do you like Mercurial?

#33
post #30

The problem with this question is that there are so many _different ways_ to use Mercurial. hg's core is fairly minimal and everyone I know who uses it rely heavily on core- and third party extensions to get any productive work done. Mercurial does a good job at facilitating everyone's favourite, yet obscure, workflow. There are people who prefer using things like mq (patchset queues), which until recently also was M…

"The problem with this question is that there are so many _different ways_ to use Mercurial. hg's core is fairly minimal and everyone I know who uses it rely heavily on core- and third party extensions to get any productive work done. Mercurial does a good job at facilitating everyone's favourite, yet obscure, workflow. There are people who prefer using things like mq (patchset queues), which until recently also was…

There's definitely a lot of baby duck syndrome on both sides of this git-vs-hg thing:

https://en.wikipedia.org/wiki/Imprinting_%28psychology%29#Ba...

Habituation is the best user interface.

Re: Ask HN: Google/FB engineers, Do you like Mercurial?

#34

The problem with this question is that there are so many _different ways_ to use Mercurial. hg's core is fairly minimal and everyone I know who uses it rely heavily on core- and third party extensions to get any productive work done. Mercurial does a good job at facilitating everyone's favourite, yet obscure, workflow. There are people who prefer using things like mq (patchset queues), which until recently also was M…

> More recently bookmarks were added (also as an extension you have to opt-in to)

Bookmarks were added to the core in mercurial version 1.8 in 2011. No configuration is needed to enable them.

Re: Ask HN: Google/FB engineers, Do you like Mercurial?

#35
post #26

Earlier quoted context omitted.

GitLab CEO here, in GitLab you can protect branches to not be rebased at all (web or command line), see https://about.gitlab.com/2014/11/26/keeping-your-code-protec... I'm not aware that GitHub offers the same functionality.

On the page where the ssh finger print is listed, can you list the RSA finger print too? I am not well versed in working with git over ssh, but after following the instructions on GitLab to generate a key, then git would keep showing me the RSA finger print which doesn't match the one provided on the website. After looking around a bit, it looks like the one listed is ECDSA. tl;dr: It was late. Finger prints didn't m…

Thanks, fixed in https://gitlab.com/gitlab-com/www-gitlab-com/commit/2493f208...

Re: Ask HN: Google/FB engineers, Do you like Mercurial?

#36
post #10

Earlier quoted context omitted.

Not exactly "all", but certainly the mother load.

Mother lode, the central, most valuable vein of buried gold.

Oh, thanks! I'll let my original spelling stand as a testament to my ignorance. :-)

Re: Ask HN: Google/FB engineers, Do you like Mercurial?

#37
post #24

Earlier quoted context omitted.

I don't believe the ability to rewrite history is a good idea. One of the reasons I like Fossil-SCM is that you can't rewrite history.

> Subversion uses a centralized revision control model. Ben Collins-Sussman, one of the designers of Subversion, believes a centralised model would help prevent "insecure programmers" from hiding their work from other team members. source: http://en.wikipedia.org/wiki/Apache_Subversion#Limitations_a... Sounds like you should be using Subversion then. Do you understand how history rewriting works in git? do you unders…

Note that Ben (a personal friend) has been an enthusiastic user of Mercurial for several (4? 5?) years, and is pretty happy with it. He was even using hgsubversion for a while I think.

Note that there's a lot of social problems around DVCS, and the thing Ben worried about is still a _real problem_. I get potential contributors showing up with months of work, and it's an enormous pain in the ass (both for them to rewrite and for me to beg them to work with me) when they did something architecturally unacceptable early in the process that a simple 2 minute review could have caught.

Re: Ask HN: Google/FB engineers, Do you like Mercurial?

#38

The problem with this question is that there are so many _different ways_ to use Mercurial. hg's core is fairly minimal and everyone I know who uses it rely heavily on core- and third party extensions to get any productive work done. Mercurial does a good job at facilitating everyone's favourite, yet obscure, workflow. There are people who prefer using things like mq (patchset queues), which until recently also was M…

It's worth noting with bookmarks that the workflow you describe doesn't even need to use bookmarks at all (and I wouldn't call when they were put into core to be "recent"). All a bookmark does is give a development line a tag that can move.
Post reply on HN