Live data from Hacker News

Mercurial developer responds to "Switch to git?"

groups.google.com

21–30 of 201 posts

Re: Mercurial developer responds to "Switch to git?"

#21
post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

Yeah, I get the impression that in most meaningful ways hg is a better choice on a technical level. But git does have a few real advantaves. Git is faster, though the difference is small enough that I can't imagine this being a serious issue. Git repo's are smaller, particular in the face of (directory) renames.

But the real advantage of git is its popularity. You present that as something worrying; but at the end of the day, hg and git aren't all that different, and popularity means pervasiveness means collaboration is easier - and that's worth something.

Re: Mercurial developer responds to "Switch to git?"

#22
I don't think Mercurial is the issue here...

Google Code is the issue... Didn't realise people still used that, its worse than Codeplex. Atleast use Bitbucket or something that makes it easier for people to contribute to while still keeping it with Mercurial.

I've found bugs in stuff before and ended up using a different project/library for the sole reason that I found out its in Google Code and the amount of effort involved in using the site let alone raising an issue or fixing it just wasn't worth it.

Re: Mercurial developer responds to "Switch to git?"

#23
post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

> (...) the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state.

It's almost impossible to leave git in "an unrecoverable state", short of actually deleting your ".git" directory.

If you do wind up in a bad spot, that's what the ref-log is for [0]. If you've made an error that is difficult or complicated to unwind, no sweat: hit the reflog and go back in time to the point where things were the way you wanted.

git is many things -- frequently useful, often complicated, sometimes obtuse. But it's almost always safe.

[0]: https://www.kernel.org/pub/software/scm/git/docs/git-reflog....

Re: Mercurial developer responds to "Switch to git?"

#24
post #16
post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

Agreed. Honestly, I see the appeal of maintaining a clean history, but shouldn't that be done in some non-destructive fashion? Do we need source-control on our source-control? Or at least simply flag squashed commits instead of destroying them?

> Do we need source-control on our source-control?

That's more or less what Mercurial's changeset evolution [1] is/will be (it's not enabled by default yet).

[1] http://mercurial.selenic.com/wiki/ChangesetEvolution

Re: Mercurial developer responds to "Switch to git?"

#25
post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

I'm guessing the reason you're getting downvoted is because it sounds like you don't know how to use git. That may not be true, it just sounds that way.

> the biggest problem by far is that git is dangerous out of the box - it can destroy your work very easily or leave you in an unrecoverable state.

Please explain. How is it dangerous? How can it leave you in an unrecoverable state?

> why can't i roll back a merge in one step if i didn't configure things to be able to do that?

Depending on how many commits the merge had it'd be something like

git reset HEAD^^ --hard

> why does my branch disappear when i merge?

What do you mean? That the branch you merged into doesn't indicate which commits were done on the other branch? Branches don't disappear.

Re: Mercurial developer responds to "Switch to git?"

#26
post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

As far as danger goes, I've never got into a state I couldn't back out of using the reflog - though the user experience surrounding getting there and back could definitely use some polishing.

As far as having mutable histories, from the standpoint of someone who has to review and integrate lots of branches from a large distributed team, its amounts to a necessary evil. It's difficult to review and merge anything more than a concise set of changes that achieve their end goal and it's also difficult to have committed such a changeset on the first try. Not having the team rebase out experimental and exploratory commits would be a huge mess and while it's an option to just wait to commit until you're done, that risks losing things, and leads to giant one-shot patches that can still be tricky to review and ship.

I'm not sure what workflows hg users that loathe to alter history adopt where they don't suffer from trying to integrate messy branches.

Re: Mercurial developer responds to "Switch to git?"

#27
post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

Nobody is saying you have to squash, it's just recommended to tidy changehistory. For all of your projects, you can simply not squash, and ask contributors to do the same. It's not like git rewrites history automatically...

Just because git will let you shoot yourself in the foot, doesn't mean that it's a tool that should be avoided.

Re: Mercurial developer responds to "Switch to git?"

#28
post #16
post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

Agreed. Honestly, I see the appeal of maintaining a clean history, but shouldn't that be done in some non-destructive fashion? Do we need source-control on our source-control? Or at least simply flag squashed commits instead of destroying them?

> I see the appeal of maintaining a clean history, but shouldn't that be done in some non-destructive fashion?

Don't rebase code that is public (few people recommend that you do) and there is nothing destructive about it. When I rebase my changes before making them public, I am not destroying history, I am deciding history.

Re: Mercurial developer responds to "Switch to git?"

#29
post #14

i am worried about the popularity of git to be honest. i'm convinced it is popular rather than good. "I've really tried to 'get into' mercurial's mindset several times now, but never could, whereas, IMO, git's model is simple and powerful. " I find it hard to understand what this means, but this is typical of the arguments i see for using git. really the core concepts of DVCS are the same no matter what tool you use,…

If your comment gets downvoted, it's much more likely to be because it is simply inaccurate.

Git is remarkably safe out of the box. Git makes it damn near impossible to lose anything other than intentionally. No matter if you rebase, reset --hard, or any other "destructive" operation, you can always get back to your prior state with nothing but a quick look in the reflog. Even if you start doing the really dangerous stuff like filter-branch, there again Git goes to pains to prevent you from losing data, by creating a refs/original folder to preserve your old refs (though you can also just use git fsck). Git goes above and beyond the call of duty when it comes to preventing data loss. Short of intentionally running the garbage collector with --prune=all right after rebasing, you won't lose data.

As for the core concepts being the same, you're talking about usage whereas the person you quoted was talking about the actual implementation-level object model. Git's model is remarkably simple, and that simplicity is the source of many of its benefits. Every other VCS out there is more complex.

Re: Mercurial developer responds to "Switch to git?"

#30
I think the big summary of this post comes down to, if you don't have something like:

    [extensions]
    shelve =
    histedit =
    rebase =
    mq =
As a git developer using hg you're going to be frustrated by all the things 'hg doesn't support'.

It doesn't actually not support them, they're just (for some reason?) shipped with hg but not turned on by default.

Post reply on HN