Live data from Hacker News

Mercurial developer responds to "Switch to git?"

groups.google.com

61–70 of 201 posts

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

#61

Ive been using perforce/p4 since 97. the last 8 years have been coupled with P4V and the eclipse plugins. My workflow is virtually identical to the much offered Git branching model [0]. Turn it -90deg with time left to right. Rename "develop" to "trunk". and think of "master" as being the release labels. release and feature branches are created from the build label of the previous release needing special changes that…

I'll mention that a number of the answers covered in this StackOverflow post [1] (note, that post is old, so it is entirely possible that perforce has improved since then) cover a number of the reasons I prefer git over perforce, but, for me, cheap branching and speed (due to everything being local) are probably the two biggest.

Cheap branching, especially, completely changed my workflow. When a branch is effectively free, and switching between branches is quick, a lot of doors are opened.

And I say this as someone who really liked perforce previously. I just think git is more capable, albeit with a higher learning curve.

[1] http://stackoverflow.com/questions/222782/git-vs-perforce-tw...

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

#62
post #17
post #8

Earlier quoted context omitted.

You should try SourceTree, it's a great Windows and Mac Git GUI client! It's free (as in beer) and also supports Mercurial.

Or for many of the world's desktop Linux developers who use Eclpipse, EGit is quite good and also free. Oh, and it works on Windows, Mac, for that matter just about any Linux platform that supports Eclipse.

Are you kidding!? I found EGit to be extremely buggy, not at all matching git's conceptual model, and difficult to use/navigate. Compared to the hg plugin for Eclipse or gti's command line it is light years behind. The only thing I use it for is viewing the history of a single file.

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

#63
post #58

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

Code is read more than it is written. Version control systems provide tools to make it simpler to read code and understand why it was written. Version control systems also define how you branch and merge, which are are hugely important concerns if you're working on a team, and still pretty important if you're working alone. Git handles branches and history management better than Mercurial does for my needs, and it ma…

Just curious, what about Git's branches and history management is better than Mercurials with the appropriate plugins turned on?

I've been able to successfully replicate all the Git use cases I can think of in Mercurial even if I think they are bad practices. Conversely, nothing I do makes git's cli anywhere near as good as hg. For me, that is the single biggest glaring problem with Git. I spend a very small minority of my time handling complicated history/branch issues as part of my major workflow and I spend an inordinate amount of time working with the interface to my source control. Git seems optimized for the minority case.

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

#64

Earlier quoted context omitted.

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…

I think this gets to one of the issues people who have previous source control experience have with git. They apply the concepts from, say, subversion to git, and then have trouble. Take branches for example. In subversion, branches were heavyweight, scary things. In git, they are extremely lightweight, in that they are really nothing more than a pointer to a specific commit. They almost shouldn't even share the same…

They apply the concepts from, say, subversion to git, and then have trouble.

I have found this to be true. I helped a lot of people at work switch from svn to git. As I showed people what to do the biggest problem was trying to make git fit in with what they knew from svn. Now I start every conversation with forget svn :)

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

#65
post #55

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

Articles like this make me wonder if I'm stupid. 95% of the time all I ever do is commit my work and push/pull, whether I'm using svn, git, or hg. I just hardly ever find myself needing to understand anything more complicated than that. Why does it seem like everyone else has spent thousands of hours understanding esoteric git or hg incantations that I've never encountered the need for.

Are you working with a large team? I find that tends to be when your "VCS muscles" really start to get exercised.

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

#66
post #7

Earlier quoted context omitted.

I use TFS at work and Git at home - I do miss Visual Studio's merge features which have been greatly improved in 2012 and 2013. How did you get your head around resolving merge conflicts in Git?

It's as easy as searching for ">>>>" in your text editor; the conflicts will be clearly marked and you take the markers out and make the merged code look the way you want it.

Or use my favourite conflict program p4merge

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

#67
post #55

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

Articles like this make me wonder if I'm stupid. 95% of the time all I ever do is commit my work and push/pull, whether I'm using svn, git, or hg. I just hardly ever find myself needing to understand anything more complicated than that. Why does it seem like everyone else has spent thousands of hours understanding esoteric git or hg incantations that I've never encountered the need for.

I know nothing about your situation, but I know from my own experience that as soon as you have multiple developers working on a project, plus staggered QA/Staging and Production deploys, things get really complicated really fast.

Then you add in stuff like experimental features (refactors, porting to new framework versions, etc.) that need to be developed alongside regular work without clobbering it, or features that get shelved while they are half-done, and things get just downright messy fast in something like SVN.

So my guess is that you aren't stupid at all, but that you just haven't had to deal with that sort of garbage.

(It's also possible your teammates simple deal with all this other crap for you, and don't bother you with the details.)

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

#68
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'd just like to respond to all the people who are saying "Use the reflog" here.

Yes, you can recover lost commits using the reflog. But it is not well publicised that you can do this. Most tutorials do not mention it and most Git GUIs do not expose it. It is also not functionality that you expect to exist, so you are not likely to think to Google it. Unless you are an advanced Git user, your commits are indeed, to all intents and purposes, lost.

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

#69
post #55

Articles like this worry me a lot. Most of this post leaves me thinking, "Why should I be worrying about things like this?" A fair amount of it leaves me at least somewhat boggled; I suspect I'm not alone here. The idea that a user of a DVCS needs to be familiar with issues like these tells me that something is seriously wrong with the design of DVCSs. Remember, a DVCS is a tool we use to track and store data related…

Articles like this make me wonder if I'm stupid. 95% of the time all I ever do is commit my work and push/pull, whether I'm using svn, git, or hg. I just hardly ever find myself needing to understand anything more complicated than that. Why does it seem like everyone else has spent thousands of hours understanding esoteric git or hg incantations that I've never encountered the need for.

I didn't need to do anything more complicated than pushing and pulling until I got my current job. Maybe it just depends on the team and codebase you're using.

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

#70

It's refreshing to see someone with a level-headed response who doesn't fly off the rails defending their source control tool of choice, unlike what you usually see with developers of well-known frameworks like PHP and Ruby. I don't personally use Mercurial myself, but it doesn't seem like a bad source control choice, anything is better than SVN, right? Git and Mercurial both seem like great and sensible choices.

Sadly no, not everything is better than SVN.

SourceSafe, CVS immediately come to mind as systems worse than SVN.

Post reply on HN