Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mercurial developer responds to "Switch to git?"

groups.google.com

Post reply on HN
Print view View original

81–90 of 201 posts

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

#81

Post by steveklabnik »

kasey_junk wrote: post #63
natrius wrote: post #58

Earlier quoted context omitted.

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…

I a not mega familiar with mercurial, but I was under the impression that culturally, rebasing is considered bad. Yes, there is a rebase plug-in, but mercurial users don't generally think it's a good idea to mutate history. Git users tend to branch, make a ton of commits, then clean them up using rebase and then merge and push. hg users tend to... not?

I may be _entirely_ off base here.

(personally I find git's command line to be fantastic, but I often feel like I'm the only one.)

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

#82

Post by rocky1138 »

sampo wrote: post #44
jlgreco wrote: post #32

Earlier quoted context omitted.

To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Of course --hard is not on by default so... there is no issue here with git's default behaviour. > "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." Yup, exactly. The simplicity of git's model is hugely important. It allows me to…

> To my knowledge, reflog won't help you get back uncommitted work that you nuked with git-reset --hard. Every version control system has a way to overwrite a dirty (modified) work directory, so git is hardly any more dangerous than any other tool. It also won't help you get back uncommitted files that you destroy with `rm`. No other tool does, either.

You can actually get back files that you rm. I've seen it done. Apparently it has something to do with unmounting the drive, restarting in single-user mode, then finding/knowing where it is on the drive before the OS overwrites it (hence the unmount).

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

#83

Post by army »

ams6110 wrote: post #55
ggchappell wrote: post #33

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.

Consider yourself lucky :). I've just learnt things as I've come across new and difficult situations.

The issues are really in dealing with multiple concurrent streams of development (multiple developers, or different branches of your own development if you have to switch between tasks). It's also useful having good tools to look at diffs and history to try to diagnose any problems.

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

#84

Post by elwin »

ggchappell wrote: post #33

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…

DVCS is a relatively new technology. We're still figuring out the best ways of designing and using it.

To continue your filesystem analogy, filesystems were invented sometime around 1960, but it was over 20 years before everyone settled on Unix-style filesystems, where files are just a sequence of bytes. Eventually, they realized implementing version control or record structures at the filesystem level was unnecessary. DVCS implementations may similarly grow more alike and become simpler.

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

#85

Post by army »

kasey_junk wrote: post #63
natrius wrote: post #58

Earlier quoted context omitted.

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…

I find git's CLI pretty efficient: most of the time it is just commit/rebase/push/pull.

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

#86

Post by jheriko »

nbouscal wrote: post #29
jheriko wrote: 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…

Your definition of safe is not mine. I have no doubt the data is preserved - 'unrecoverable state' is too strong.

Its not safe in the sense that if i make a change on submission day and need to revert it then its more complicated than it needs to be. Granted I should not be using something I don't have sufficient mastery of in that kind of scenario, but its not always so simple.

My data being 'safe' is worthless if there is a steep learning curve to recovering it.

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

#87

Post by steveklabnik »

jxf wrote: post #23
jheriko wrote: 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…

> git reflog

This, a thousand times this. Unless you happen to randomly run `git gc` for some odd reason, you have a few months (with default settings) until your repo is in an unrecoverable state, unless you touch the .git directory directly.

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

#88

Post by eru »

encoderer wrote: post #74

Having used both extensively, Git at one job, HG at the next, now Git again, I mostly have this to say: Both tools lack polish. The biggest piece of mis-information I'd like to clear up is that often times a user new to either of these makes a few mistakes and then the cold hand of death grabs them and they're certain they lost work. You never really do. In Mercurial, the permanent nature of named branches and in Git…

I've used patch queues with hg, but there are other tools available. For example bookmarks allow you to use hg more like git.

Hg with patch queues is a bit like using git and always rebasing, almost never merging. You do lose history with patch queues.

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

#89

Post by jheriko »

driverdan wrote: post #25
jheriko wrote: 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…

This is precisely true. I don't know how to use git. That's a big part of the problem I have with it, I get much more bang for my buck in terms of time spent working things out if I don't use git.

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

#90

Post by eru »

MikeTLive wrote: post #78
rallison wrote: post #61

Earlier quoted context omitted.

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…

you found the same one that i did while editing. if git is great, is it worth changing an enterprise to use it? when the auditors come, I need to list the changes on a server. when its an app, the changes to that app. who, what, when, where, why - reviewer, requestor, approver, author, deployer, etc.etc.etc. how granular and how far back can i get this with GIT? how solid is the nonrepudiation factor with GIT? for co…

Does perforce provide cryptographic checksums? If not, git is actually a win as far as the auditors are concerned. git does not allow any changes to history.

You can make new history and garbage-collect the old history. But for a fixed commit hash, all history and all contents are fixed forever. For extra security, you can sign the commits (ie their hashes) with your PGP key.

> how solid is the nonrepudiation factor with GIT?

Rock solid: as far as I can tell (from https://en.wikipedia.org/wiki/Perforce) in Perforce you have to trust your admin not to go behind your back and change history. In git you have cryptographic hashes to protect your history and content.

> for security - can i protect others from getting the code?

git leaves the protection to the file system permissions.

git doesn't track who requested a change nor why. People usually do this via conventions in their commit messages. You can write plug-ins to enforce these conventions.

Post reply on HN