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

141–150 of 201 posts

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

#141

Post by pjmlp »

gkoberger wrote: post #40
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…

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…

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

This is my mindset. I do have my preferences, but it is all about what technologies our customers require.

So I tend to say I am language and OS agnostic.

The hard lesson about this came from the time I was still trying to get into the game industry and was spending more time thinking about FOSS technologies for game development, than the game design itself. After getting a foot into the industry, it became clear to me that what matters is getting a game released, the technology religion has no place.

So nowadays I always advocate the goal is to have a project done and solve the customer problems. The technology used for it is secondary.

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

#142

Post by kderbe »

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…

I have no experience with perforce so I cannot directly compare it to git. Some of the things you ask for can be done with git. As eru mentioned, you can sign a commit (and therefore all history leading to that commit), which will prevent anyone else from modifying its history undetected. With abundant signing and tagging, you could probably create a thorough audit trail.

Git by itself does not have granular access control, and relies on filesystem permissions for security. The most common tool I know of to finely control write access to git (other than GitHub) is gitolite[0]. But even gitolite only provides read access control at the repository level.

[0] What is gitolite? http://gitolite.com/gitolite/index.html#what

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

#143

Post by gcb0 »

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…

Spot on. The whole thread can be summarized as "dev do not get either mercurial not git, complains they want to use git because they have more workflow articles on reddit to copy paste solutions"

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

#144

Post by qznc »

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

Repeating my description: Git internally is just snapshots of the code connected with prev-version edges forming a directed acyclic graph and then some named pointers into this DAG.

This is the simplicity of git. I do not use or know Mercurial, but from the article Mercurial seems to have multiple types of branches and commits. This makes it more complex.

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

#145

Post by jheriko »

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…

I appreciate the effort you have made in trying to educate me here - reflog does look like it might have helped to solve my problem although it is extremely non-obvious even after running it. (i.e. i know i need to google or read something else rather than how to solve the problem).

I have recreated the problem I originally had and documented precisely why it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh.

http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

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

#146

Post by jheriko »

steveklabnik wrote: post #87
jxf wrote: post #23

Earlier quoted context omitted.

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

I appreciate the effort you have made in trying to educate me here - reflog does look like it might have helped to solve my problem although it is extremely non-obvious even after running it. (i.e. i know i need to google or read something else rather than how to solve the problem).

I have recreated the problem I originally had and documented precisely why it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh.

http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

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

#147

Post by jheriko »

rallison wrote: post #130
jheriko wrote: post #121

Earlier quoted context omitted.

'- Revert the merge commit' this is what i had problems with. i got an error message back from git that you can't revert a branch commit and when i googled it the conclusion i came to was i needed to go back in time and change our configuration to make this possible. its entirely possible that i ended up down the wrong path from google searching. now, googling around i find some stack overflow answers and such i'm pr…

I completely agree that reverting a merge in git is painful (painful, that is, in figuring out the parameters to pass to git revert). Let's say this is your scenario: d Merge branch 'test' |\ | c-test Test Branch Commit 1 b | Master Commit 2 \| a Master Commit 1 And let's say you want to revert d, the merge commit. You would do this: git revert -m 1 HEAD Now your history looks like this: e-master Revert "Merge branch…

I appreciate the effort you have made in trying to educate me here.

I have recreated the problem I originally had and documented precisely why it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh.

http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

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

#148

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…

I appreciate the effort you have made in trying to educate me here.

I have recreated the problem I originally had and documented precisely why I think it really is a usability problem. Now that I have done this I am pretty sure that my anti-git sentiment is warranted - even if my initial comment was massively too harsh.

http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

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

#149

Post by jheriko »

qznc wrote: post #144
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,…

Repeating my description: Git internally is just snapshots of the code connected with prev-version edges forming a directed acyclic graph and then some named pointers into this DAG. This is the simplicity of git. I do not use or know Mercurial, but from the article Mercurial seems to have multiple types of branches and commits. This makes it more complex.

everything is a changeset, and yes there are multiple types but for the end user they have no need to know about them - from there perspective everything is a changeset and they are all operated on equally.

from the end user perspective git does have multiple types of change - and this was precisely my problem. i recreated the problem and documented it here:

http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

to be fair, i completely took that quote that I used about simplicity out of context because I've heard similar said in a different context more than once and I jumped to a conclusion.

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

#150

Post by jheriko »

jlgreco wrote: post #115
jheriko wrote: post #108

Earlier quoted context omitted.

this is a terrible analogy, its more like 'i can't drive this car if i don't do an engine rebuild myself - maybe i'll drive this car that already works the way i want' tbh, i started a place they used git, i started learning it but nobody already there knew a damned thing about it and they should have been using it at all. they used it because it was more popular, despite having history with mercurial. we now use mer…

Engine rebuild of git? You mean "learn how to use it" . If you want to go with a car analogy, then it is more like you are going to keep on driving one car because you don't know how to drive the other. Git isn't broken just because you don't know how to use it.

Now that I have recreated my original scenario I am now firmly of the belief that the interface to the user, documentation and available reference are inadequate.

http://jheriko-rtw.blogspot.com/2013/11/why-i-hate-git.html

Hopefully I can claw back some of the respect that I have clearly lost from you. Or at least discourage you from being so offensively defensive about this. :)

Post reply on HN