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

51–59 of 59 posts

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

#51

Post by mpdehaan2 »

leni536 wrote: post #20
mpdehaan2 wrote: post #14

Earlier quoted context omitted.

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

No it's not, it rewrites and destroys history. The problem it solves is "keeping the history clean", when actually it's not what you want. You don't see your history, you see logs and diffs. So you want to keep your logs and diffs clean. There should be an other solution to this other than simply removing/merging commits and eventually removing information with it.

if you read my post, "history" on local branches is irrelevant. They do not exist and "destroy" here is totally fine. It's not like it's meant to be a grand book detailing all the work done by you, in every point in time, as a database record. What you want here instead is just a clean patch coming off your topic branch -- which this does perfectly.

This is SUPREMELY valuable for OSS patch workflow and I absolutely love git for having it.

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

#52

Post by mpdehaan2 »

dajobat wrote: post #32
mpdehaan2 wrote: post #14

Earlier quoted context omitted.

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…

Rebase is not just a history win, but also a patch review win.

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

#53

Post by sytse »

sytse wrote: post #35
c0wb0yc0d3r wrote: post #29

Earlier quoted context omitted.

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

Also, we added all other keys: https://gitlab.com/gitlab-com/www-gitlab-com/commit/79bdb63f...

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

#54

Post by thanksgiving »

leni536 wrote: post #47
brusch64 wrote: post #41

Earlier quoted context omitted.

We had the same discussion in my office. If I am developing a feature (in a separate branch) - why shouldn't I rebase to make a single commit out of this feature ? Is this really interesting for you that it took me 10 commits to do sO ? Even if one of the commits was just a "I have to switch an fix a bug and want to commit before switching to another branch" - commit ? I think there is nothing wrong with rebasing and…

I don't think it's wrong when using git. However I think it shouldn't be designed like this though. Git rebase should add metadata not remove them. Essentially you rebase because you want to hide certain details because they are not important. Rebase could do one or more actual merges instead and mark certain commits not important so they wouldn't show up in logs by default. AFAIK rebase is the only operation that ha…

The way I understand it, I should only rebase (for squashing, not in the case of a spilled secret or inappropriate message) if I haven't pushed it to a shared remote branch. Is that correct?

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

#55

Post by brusch64 »

thanksgiving wrote: post #54
leni536 wrote: post #47

Earlier quoted context omitted.

I don't think it's wrong when using git. However I think it shouldn't be designed like this though. Git rebase should add metadata not remove them. Essentially you rebase because you want to hide certain details because they are not important. Rebase could do one or more actual merges instead and mark certain commits not important so they wouldn't show up in logs by default. AFAIK rebase is the only operation that ha…

The way I understand it, I should only rebase (for squashing, not in the case of a spilled secret or inappropriate message) if I haven't pushed it to a shared remote branch. Is that correct?

That's how I am using rebase all the time. I'd say yes - that's the most common use for it and I think it works fine for this.

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

#56

Post by gcb0 »

lifebeyondfife wrote: post #16
gcb0 wrote: post #8

heavy mercurial user. all my open source projects are on it. first at Google code (rip) and now on bitbucket. though i have to use git at work daily. github to add insult... my finger memory is now on git. and that's where git "wins". the chance that you will be forced to use it and learn the awful laundry list of steps to properly use it (hint, if you ever type "pull" you are doing it wrong) you get your finger memo…

> 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. but tomorrow, when you are used to type git pull, you will run it on a branch with changes and you have no idea if it will rebase, merge, fast forward... and /then/ you will see the problem. (and open yet another stackoverflow question on how to undo the last merge :)

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

#57

Post by gcb0 »

c0wb0yc0d3r wrote: post #27
ehotinger wrote: post #19

Earlier quoted context omitted.

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?

but it tries to be smart about how to merge. and usually it's not what you want. i consider it the clippy of linus.

if you run merge/rebase/etc on its own, it will tell and ask you about anything out of the ordinary and then there's no surprise.

again, it's all about avoiding errors on the rare cases because you developed dangerous finger memory.

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

#58

Post by gcb0 »

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.

but you still damage your local copy and it's a pain to clean up, specially if you had local changes/commits

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

#59

Post by sytse »

gcb0 wrote: post #58
sytse wrote: 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.

but you still damage your local copy and it's a pain to clean up, specially if you had local changes/commits

The idea is not to have upstream rebases so you can't pull them by accident.
Post reply on HN