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

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

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 59 posts

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

#21

Post by lifebeyondfife »

leni536 wrote: post #18
lifebeyondfife wrote: post #16

Earlier quoted context omitted.

> hint, if you ever type "pull" you are doing it wrong Genuine question: what's wrong with executing 'git pull' on a branch you haven't changed locally?

It could be rebased upstream. While it's a really bad practice, it could happen.

Ah ok, I think I understand the concern. So 'git fetch' and 'git merge' explicitly will stop an upstream rebase from making destructive changes to the history of your local branch(?)

As you say it's bad practice and shouldn't happen. I use gitlab and GitHub where branches can be protected to only allow merges via their web interfaces.

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

#22

Post by lifebeyondfife »

ehotinger wrote: post #19
lifebeyondfife wrote: post #16

Earlier quoted context omitted.

> hint, if you ever type "pull" you are doing it wrong Genuine question: what's wrong with executing 'git pull' on a branch you haven't changed locally?

Nothing unless you're rebasing upstream, but I think the point he was trying to make was that you should always run `git fetch` and then `merge` from there (again, there are some situations where the pull is fine IMHO).

Beat me to it.

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

#24

Post by voidr »

dcuthbertson wrote: post #13
thanksgiving wrote: post #6

Earlier quoted context omitted.

I've never used mercurial outside of TortoiseHg. In fact, the only time I've used mercurial is when I was attempting to build Firefox from source before I realized that they do a git mirror thing so you don't have to touch mercurial at all. I don't know much about mercurial. I use git because somebody said it is easier to rewrite history in git.

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 understand why it's there? do you understand why people use it?

Personal beliefs don't advance computing, hard facts do.

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

#25

Post by leni536 »

lifebeyondfife wrote: post #21
leni536 wrote: post #18

Earlier quoted context omitted.

It could be rebased upstream. While it's a really bad practice, it could happen.

Ah ok, I think I understand the concern. So 'git fetch' and 'git merge' explicitly will stop an upstream rebase from making destructive changes to the history of your local branch(?) As you say it's bad practice and shouldn't happen. I use gitlab and GitHub where branches can be protected to only allow merges via their web interfaces.

I don't think git pull would ever destroy your history (AFAIK it's exactly the same as a fetch+merge), at worst you end up in a merge conflict, but it's easily revertable. However after a git fetch and a git log you can see beforehand if there is anything nasty going on.

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

#26

Post by sytse »

lifebeyondfife wrote: post #21
leni536 wrote: post #18

Earlier quoted context omitted.

It could be rebased upstream. While it's a really bad practice, it could happen.

Ah ok, I think I understand the concern. So 'git fetch' and 'git merge' explicitly will stop an upstream rebase from making destructive changes to the history of your local branch(?) As you say it's bad practice and shouldn't happen. I use gitlab and GitHub where branches can be protected to only allow merges via their web interfaces.

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.

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

#27

Post by c0wb0yc0d3r »

ehotinger wrote: post #19
lifebeyondfife wrote: post #16

Earlier quoted context omitted.

> hint, if you ever type "pull" you are doing it wrong Genuine question: what's wrong with executing 'git pull' on a branch you haven't changed locally?

Nothing unless you're rebasing upstream, but I think the point he was trying to make was that you should always run `git fetch` and then `merge` from there (again, there are some situations where the pull is fine IMHO).

git pull just runs git fetch then git merge.

At least that is what the docs say: http://git-scm.com/docs/git-pull

What am I missing?

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

#28

Post by krupan »

dcuthbertson wrote: post #13
thanksgiving wrote: post #6

Earlier quoted context omitted.

I've never used mercurial outside of TortoiseHg. In fact, the only time I've used mercurial is when I was attempting to build Firefox from source before I realized that they do a git mirror thing so you don't have to touch mercurial at all. I don't know much about mercurial. I use git because somebody said it is easier to rewrite history in git.

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.

Do you ever write code, test it, and then edit that code some more? If so you just "rewrote" history. The history in the VCS is whatever you decide it to be when you actually commit. You can carefully shape what the history looks like with any VCS by being careful about what you commit. Git and mercurial simply allow you to shape the history after committing as well.

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

#29

Post by c0wb0yc0d3r »

sytse wrote: post #26
lifebeyondfife wrote: post #21

Earlier quoted context omitted.

Ah ok, I think I understand the concern. So 'git fetch' and 'git merge' explicitly will stop an upstream rebase from making destructive changes to the history of your local branch(?) As you say it's bad practice and shouldn't happen. I use gitlab and GitHub where branches can be protected to only allow merges via their web interfaces.

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 match. Only logical assumption was NSA. :P (Not really, obviously, but the finger prints could be more clear.)

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

#30

Post by krupan »

andreastt wrote: post #11

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 Mozilla's recommended workflow. Queues are a novel way to organise your work in progress, but is quite different from what people are used to coming from svn or git."

Up to this point your comment was true, objective, and very helpful (though I would remove the word "obscure"). Then it starts to sound like maybe you learned git first and got used to it's defaults and now mercurial tastes a little funny to you. I'm guessing this because I got good with mercurial first and then when I tried git it left a funny taste in my mouth. I thought, what is this "fast-forward merge" that doesn't actually merge anything? Why do people talk about deleting a branch when it doesn't actually delete the branch of commits in the DAG of commits, just a pointer? Why does pull do a pull (fetch) and merge (mercurial's pull just pulls, or fetches, I guess)? Stuff like that.

Post reply on HN