Live data from Hacker News

Mercurial developer responds to "Switch to git?"

groups.google.com

51–60 of 201 posts

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

#51

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…

"Perforce, maybe, but only for certain very specific scenarios."

These days you can get a lot done using git as your perforce client but.... ick.

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

#52

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…

Taking your logic a bit further: the final product is what we (should be) interested in. Python or C++ or LaTeX or whatever are just to help us make it. Everything else, whether it be Python or git or C++ or Mecurial or vim or Windows or an ergonomical mouse, is just there to help us make the final product in an easy and quality manner. I don't see a problem with worrying about git any more than I see one with worryi…

That's an interesting point. Here are my off-the-top-of-my-head thoughts:

I guess the real goal is proper separation of responsibilities. When I cook a meal, I use devices that run on electricity. I want to be able to power them up by plugging them in without thinking much about it. The people who work at my power company need to think about the intricacies of generating and transmitting electricity, but I don't want to. On the other end, the people who eat the food I cook should not have to worry about the use of a stove timer or a rice cooker.

Similarly, when I put together a software package, I am functioning as a programmer/software designer. I am interested in the code, how it is structured, and what it is supposed to do. Time spent worrying about storage & version management is generally time spent away from my primary task. Someone needs to worry about that, but, for the most part, I don't think it should be me.

The users of the package I write just want to use it. They care that it does what they want. The fact that it is written in Python, developed using agile methods, etc. are irrelevant to them. (But not to me, as a programmer.)

And maybe for the users, the software is a tool to help them in their business. The customers of that business probably should not care about the software at all; they just want whatever service the business provides.

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

#53

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.

I'm not sure about shelve, but histedit, rebase, and mq are all history modifying extensions. Mercurial differs from git in that it prefers immutable history.

The extensions are there if you really need them, not as something you should always setup imo.

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

#54
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,…

> git is dangerous out of the box - it can destroy your work very easily

I really wonder what do you mean by that?

Yes, it's relatively easy to checkout some older commit and end up in a headless state, where an ordinary `git log` command won't show your more recent commits. And then panic and think that git has destroyed your work. But all your commits are still there. You need some more involved way (like the reflog) to get back to them, but git has not destroyed them.

After 30 days or so, git may run garbage collection and remove dangling commits, thus really destroying your work then. But your words "can destroy your work very easily" are a bit strong if this is what you mean?

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

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

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

#56
post #45

Earlier quoted context omitted.

That's not correct, you can get back to any ref in the reflog, including those that you moved away from with git-reset --hard. Those commits are just dangling but are easy to get back to. I've got a presentation [1] that goes into how to use the reflog and how the various flags in reset work (among other things) that could explain more. [1]: http://tednaleid.github.io/showoff-git-core-concepts/

My point is that git-reset --hard can remove data from the working tree filesystem that never hit the DAG in the first place: $ git init Initialized empty Git repository in /home/john/tmp2/.git/ $ echo "foo" > foo $ git add foo $ git commit -m 'init' [master (root-commit) 84fb5d1] init ... $ echo "bar" >>foo $ cat foo foo bar $ git reset --hard HEAD HEAD is now at 84fb5d1 init $ git reflog 84fb5d1 HEAD@{0}: commit (i…

Ok, yes, I agree with that clarification (and I missed that you specified in your original comment "uncommitted work", my mistake).

If you git reset --hard and you have a dirty working directory, you can absolutely blow work away. That's one of the main reasons to use git reset --hard, but I agree that it needs to be used with intention.

The easiest way to protect against it is to never use it if you have a dirty working directory, always commit first and then reset --hard after you've committed.

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

#57

Earlier quoted context omitted.

Taking your logic a bit further: the final product is what we (should be) interested in. Python or C++ or LaTeX or whatever are just to help us make it. Everything else, whether it be Python or git or C++ or Mecurial or vim or Windows or an ergonomical mouse, is just there to help us make the final product in an easy and quality manner. I don't see a problem with worrying about git any more than I see one with worryi…

That's an interesting point. Here are my off-the-top-of-my-head thoughts: I guess the real goal is proper separation of responsibilities. When I cook a meal, I use devices that run on electricity. I want to be able to power them up by plugging them in without thinking much about it. The people who work at my power company need to think about the intricacies of generating and transmitting electricity, but I don't want…

Even when powering electronics in the home, you have to worry about which sort of power the device needs. Does it need a great big 240V AC outlet, or just the regular 120V AC (using American values...)? Is the device DC powered instead? Does it have it's own wall-wart, or can you use a AC->USB converter? Does it use USB micro or mini?

These are things the consumer has to worry about. Of course in practice "worry about" is an exaggeration; this is all pretty elementary stuff and no reasonably intelligent consumer actually loses sleep over it.

The matter of what version control to use? The consumer never has to worry about that. That concern is something that only developers (and related professionals) will have to worry about. I don't think it is a big deal. Just pick whatever fits your needs and that you prefer.

Should the developer have to know anything about version control? I don't know, should the electrical have to know anything about multimeters, outlet testers, and wire cutters?

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

#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 makes a huge difference to me.

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

#59

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.

I'm not sure about shelve, but histedit, rebase, and mq are all history modifying extensions. Mercurial differs from git in that it prefers immutable history. The extensions are there if you really need them, not as something you should always setup imo.

Modifying local history is not dangerous, so I think mq is good. Never really used histedit and rebase.

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

#60
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,…

You'll note that the Jenkins guys were able to recover all their work. They also use a non-standard branching and access model.

Did they? Last I heard, they were having trouble with a few repos, because the hashes they got from github weren't quite right.
Post reply on HN