Ask HN: Google/FB engineers, Do you like Mercurial? • Hacker News Board

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

#41

Post by brusch64 » Thu, May 07, 2015, 2:38 PM UTC

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.

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 to merge commits before pusing them.

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

#42

Post by jordigh » Thu, May 07, 2015, 2:40 PM UTC

heyts wrote: post #40

Honest question: could someone summarize why would one use mercurial vs git? Both seems really close in features. What would be a use case where one would outshine the other?

I promise I'll turn this FAQ you just posed into a wiki page... in the meantime,

https://news.ycombinator.com/item?id=9467096

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

#43

Post by btreecat » Thu, May 07, 2015, 2:47 PM UTC

voidr wrote: post #24

dcuthbertson wrote: post #13

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…

>Do you understand how history rewriting works in git? do you understand why it's there? do you understand why people use it?

I do not. Could you please explain?

At work I learned to use mercurial and never felt the need to pick up git since I can use the hg-git plugin.

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

#44

Post by Kiro » Thu, May 07, 2015, 2:52 PM UTC

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

Why?

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

#45

Post by krupan » Thu, May 07, 2015, 3:50 PM UTC

btreecat wrote: post #43

voidr wrote: post #24

Earlier quoted context omitted.

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

>Do you understand how history rewriting works in git? do you understand why it's there? do you understand why people use it? I do not. Could you please explain? At work I learned to use mercurial and never felt the need to pick up git since I can use the hg-git plugin.

First of all, the history re-writing of both git and mercurial do not throw any history away[1], let's be clear on that. The history re-writing allows you to commit willy-nilly as often as you want, and then allows you to clean up those commits to make them readable, useful, and presentable to your team by combining commits, reordering commits, deleting commits, etc. The freedom to commit (and have an undo-point to go back to) at any time is very liberating and anxiety reducing :-)

Using VCS's other than git and mercurial people still end up doing essentially the same thing, they are simply required to do all the cleanup outside of the VCS before they commit. Almost nobody commits every sloppy, intermediate, untested edit of their files to svn or perforce. Users of those VCS's "rewrite" and "throw away" history just the same.

Footnote:

1. They both keep the original commits around after they are replaced by "rewritten" or "edited" commits. git does eventually delete the old history with its garbage collection, but it takes a number of weeks for that to happen. Mercurial saves backup bundle files (or obsolete changesets if using the evlove plugin) indefinitely. You have to manually delete them.

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

#46

Post by krupan » Thu, May 07, 2015, 3:55 PM UTC

durin42 wrote: post #37

voidr wrote: post #24

Earlier quoted context omitted.

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

But would the insecure people have done that work at all if they knew they would be forced to commit it publicly? Maybe so, but would it all be one huge commit to svn instead of maybe a string of more concise commits to git or mercurial?

I just envision someone insecure (like I feel at times) saying, well, I'll just clone this and play around on my own machine. Then after making some commits and building up courage, saying, OK, I'll try and go public with this. With centralized VCS that seems less likely to me. The insecure programmer just won't even try. I don't know, it's probably different for different people.

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

#47

Post by leni536 » Thu, May 07, 2015, 4:28 PM UTC

brusch64 wrote: post #41

leni536 wrote: post #20

Earlier quoted context omitted.

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.

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 happily destroys your history without any --force or --hard option. It always disturbed me.

There is a legitimate usage of rebase though: you really want something removed from history. Like you accidentally committed a secret, inappropriate message or you just want to fix a typo in the last commit.

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

#48

Post by limeyx » Thu, May 07, 2015, 8:00 PM UTC

allersj wrote: post #12

Fenume wrote: post #7

Earlier quoted context omitted.

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

For me, I tend to commit frequently, sort of like my obsession with constantly hitting CTRL-S while working in an IDE. Before I push my changes I like to squash the commits into more cohesive commits. If anything, I think it makes it easier on my colleagues for code review.

Thats not the same kind of rewriting history because its local to you and hasn't yet been pushed out to others.

Git allows you to push commits to other people and then rewrite history, which is different

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

#49

Post by allersj » Thu, May 07, 2015, 8:49 PM UTC

limeyx wrote: post #48

allersj wrote: post #12

Earlier quoted context omitted.

For me, I tend to commit frequently, sort of like my obsession with constantly hitting CTRL-S while working in an IDE. Before I push my changes I like to squash the commits into more cohesive commits. If anything, I think it makes it easier on my colleagues for code review.

Thats not the same kind of rewriting history because its local to you and hasn't yet been pushed out to others. Git allows you to push commits to other people and then rewrite history, which is different

Ah, gotcha. Thanks for the clarification.

I knew that pushing a rewritten history was possible, but I can't think of any situation where I would ever want to do that.

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

#50

Post by allersj » Thu, May 07, 2015, 8:55 PM UTC

jordigh wrote: post #17

allersj wrote: post #12

Earlier quoted context omitted.

For me, I tend to commit frequently, sort of like my obsession with constantly hitting CTRL-S while working in an IDE. Before I push my changes I like to squash the commits into more cohesive commits. If anything, I think it makes it easier on my colleagues for code review.

I do the same in hg. I do `hg amend` all the time to keep adding changes to my commit. At the end I may selectively undo some changes with `hg uncommit --interactive` or `hg uncommit --all` and redo the whole thing piecemeal with `hg commit --interactive` in order to slowly split up my work into several commits. Evolve makes it really easy to keep (and ignore!) a meta-history of all of my editions, with a clear linea…

Thanks, that is useful to know.

Mercurial was my first DCVS and I loved using it, but I only touched on the basic features. I stopped using it when I switched jobs and to become proficient with git. I'll have to give it another try with one of my side projects.