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

151–160 of 201 posts

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

#151

Post by jxf »

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

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…

I agree that git can be characterized as having some usability issues; I initially found the documentation obtuse in many places.

My favorite git joke, by far: "git gets easier once you get the basic idea that branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space."

If you're having trouble understanding git but you find yourself comfortable with basic CS terms, you might want to check out Git for Computer Scientists [0]. This really helped put it in perspective for me.

[0] http://eagain.net/articles/git-for-computer-scientists/

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

#152

Post by Mithaldu »

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

The git model can be, to a sufficient degree of completeness, be demonstrated with child toys: http://www.youtube.com/watch?v=1ffBJ4sVUb4

I can't even imagine how a similar demonstration would look like with Mercurial. It would probably involve having a bunch of such trees on the table, and super-glue instead of sticking things together.

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

#153

Post by jheriko »

MAGZine wrote: post #27
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,…

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.

thanks for the suggestion, i did recreate my problem so that i could present a properly reasoned argument rather than a ragey comment:

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

i'm pretty sure that i need to do this particular shooting myself in the foot to be able to do work unfortunately. i might be lacking knowledge, but it was far too difficult to acquire said knowledge. as someone who self taught himself programming in many languages,classically hard stuff like functional calculus, quantum field theory and general relativity - as much as that is a weak argument - i'm inclined to think there is insufficient information, or at least extremely poor documentation here.

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

#154

Post by jheriko »

emn13 wrote: post #21
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,…

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…

you are correct. its popularity is an advantage, and this is precisely why i would want to use git - so many people are familiar with it and it almost seems like the standard solution today for source control.

but its still worrying to me for its popularity. either i am fantastically stupid or people are happily using a tool without any idea what they are doing or how to resolve what i consider to be a very standard source control problem. these are both things for me to worry about.

if you are wondering what i had such a hard time with here is a trivialised example:

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

even if this problem is solvable and there is a solution this is a perfectly good way to approach problem solving - the problem is the lack of quality documentation and source materials to research a solution from.

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

#155

Post by tripa »

jlgreco wrote: post #45
tednaleid wrote: post #42

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…

I'd be surprised if mercurial didn't have a similar “feature”.

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

#156

Post by skriticos2 »

acjohnson55 wrote: post #75
tednaleid wrote: post #56

Earlier quoted context omitted.

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

I guess maybe the counterargument is that perhaps this should happen invisibly and automatically.

You just ran a script that scattered production / sensitive information in your source files. You definitely don't want to get that into history and get the last head state back.. Yes, you can delete the working tree and check out head again, but than again, git reset --hard pretty much does that and it's welcome at times.

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

#157

Post by jheriko »

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

as a note this seems to have +36 points, i assumed it was negative because my reputation seems to have taken a dive by roughly that same value. just noticed in my history that negatives are marked with a '-' and get greyed out. how strange... or perhaps i am again just being stupid.

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

#158

Post by mrtngslr »

natrius wrote: post #96
kasey_junk wrote: post #63

Earlier quoted context omitted.

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…

To use bookmarks, I have to convince the whole team to use bookmarks. Why not convince them to switch to git instead? I use Mercurial plugins to give me commands that make my life better, like `pull --rebase`, `shelve` and `strip`, but getting coworkers on the bandwagon requires explaining which extensions to install instead of pointing to the man page for the appropriate command. My git workflow is probably replicab…

(OP here) You don't need to tell the rest of the team if you're using bookmarks, just like you don't need to tell the rest of your team the names of your Git branches.

Bookmarks stay local by default, but they can be exported to the server if you like. There's nothing to enable any longer since it's a core feature.

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

#159

Post by rallison »

jheriko wrote: post #147
rallison wrote: post #130

Earlier quoted context omitted.

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

Ah, and this is why I shun fast forward merges. You were using fast forward merges (and, honestly, I absolutely cannot blame you for doing so). A very, very simple graphic explaining the difference can be seen here:

http://stackoverflow.com/a/2850413/1397661

The fast forward merge loses any concept of where the branch was branched from and when it was merged back in. Many in the community find the fast forward version cleaner. Sure, it is cleaner, until you need to revert that merge.

After using git professionally for quite a while, my opinion is that one should almost always use --no-ff for merging (unless one really knows better). Sure, the history is a bit more complicated to view. But, if you want to easily revert that one merge, everything becomes much, much simpler. It adds a little complexity for the common case while significantly reducing the complexity for a number of slightly less common cases.

That said, this ties back into the learning curve of git. How were you to know that you should do non-fast-forward merges so as to make merge reverts easier? Git has probably the steepest learning curve of any current version control system. It takes time to figure out the proper workflow for a company, and I've seen many rather intelligent people fail at git.

By the way, you brought up valid points and questions, and I enjoyed this discussion.

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

#160

Post by CmonDev »

riannucci wrote: post #77

Author/thread starter here: Really didn't think this post would have generated as much interest as it did when I created it... :D It's a fairly enlightening thread though. Mad props to Martin for a fantastically thoughtful reply!

So, you are not switching now, hopefully?
Post reply on HN