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

101–110 of 201 posts

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

#101

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.

Actually it does rewrite history by default AFAIK. This is how the merges work from the end user perspective.

I've never had trouble reverting a merge in any other context.

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

#102

Post by rallison »

jheriko wrote: post #95
rallison wrote: post #48

Earlier quoted context omitted.

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…

The specific experience I have is being able to revert a merge painlessly with a single operation out of the box. This was unreasonably challenging with git. AFAIK there is no command for this out of the box and my research led me to believe I could only fix it for future commits by making other changes. That's not acceptable and utterly destroyed my confidence in every other feature. Why in as source control solutio…

Oh, reverting merges! I've been there, and it is completely possible, out of the box, with git. But! It requires a relatively thorough understanding of how it works, or you will definitely mess it up. I wrote up this summary a while back for our company wiki:

Imagine this scenario:

- Team Sandy does a ton of work on branch foo.

- Team Sandy ensures the release manager that branch foo is perfect and bug free.

- Team Sandy merges branch foo into branch develop and pushes.

- Other developers continue committing to develop.

- Massive devastation and destruction start occurring due to massive bugs scattered throughout Sandy's code.

At this point, we want to get all of Sandy's code out of develop, as we can't post to production until develop is Sandy-free. What do we do?

- Revert the merge commit

The important thing to note here is that this basically undoes the effect of the merge, but NOT the history. If you were to try to merge branch foo back in at a later date, git would do nothing and tell you that everything is already merged in. This is technically correct, but confusing.

Let's imagine that Sandy goes back to branch foo and commits bug fixes to fix the devastation. Now, branch foo is ready to be merged back in. What do we do?

- Revert the revert commit (yes, really). This basically undoes the effect of our original undo. At this moment, develop has all of branch foo's code pre-bug fixes.

- Merge foo into develop. This merges the subsequent bug fix commits into develop.

A much more thorough discussion can be enjoyed here (I highly recommend the read): https://www.kernel.org/pub/software/scm/git/docs/howto/rever...

--

Basically, it can be done with one line on the commandline, but I wouldn't recommend anyone do it unless they've read the above (specifically, the discussion I've linked to).

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

#103

Post by jheriko »

androsynth89 wrote: post #31
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,…

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

yeah, but did you read about what they were doing? granted the breaker of it all did something he shouldn't have... but its still terrifying to hear of these things.

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

#104

Post by riannucci »

hrjet wrote: post #92
matwood wrote: post #36

Earlier quoted context omitted.

My normal workflow with git is through the cli. Cli really is the best way to use it since git is good at prodding you along to do the right thing. Make sure to go find a good set of aliases and turn on git prompt. When I need to look at histories or large change sets I'll open up SourceTree or go to the BitBucket repos. If I need to see the file history of a single file gitk -p -- file is the quickest way that I hav…

What is "git prompt" and how do I turn it on? A quick search didn't reveal anything.

I think the parent is meaning something like the git-status integration of e.g. oh-my-zsh [0], or something like the 'official' git-status integration script for bash [1]

(I've used the former, but not the latter.)

[0] https://github.com/robbyrussell/oh-my-zsh [1] https://raw.github.com/git/git/master/contrib/completion/git...

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

#105

Post by leokun »

philliphaydon wrote: post #22

I don't think Mercurial is the issue here... Google Code is the issue... Didn't realise people still used that, its worse than Codeplex. Atleast use Bitbucket or something that makes it easier for people to contribute to while still keeping it with Mercurial. I've found bugs in stuff before and ended up using a different project/library for the sole reason that I found out its in Google Code and the amount of effort…

Agreed, Google Code is awful. The tree ui for browsing code is so very terrible. Browsing commits is a terrible pain. Viewing diffs is awful. And the site just looks ugly and is hard to use. I was tired of Google Code before I even knew about GitHub, I had switched to Unfuddle.

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

#106

Post by functional_test »

steveklabnik wrote: post #81
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…

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

Exactly. Although rebasing is convenient, it does involve taking destructive actions on a repository which is ostensibly a tool to make sure your data isn't lost. The feeling in the Mercurial community is that this is potentially dangerous and not necessary.

Really, it would be best if there was some way to retain the original commits while rebasing to clean the history. Time for a new DVCS?

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

#107

Post by jlgreco »

jheriko wrote: post #89
driverdan wrote: post #25

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…

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.

I don't know how to operate a airplane, but that isn't a problem I have with airplanes. That is a problem I have with myself.

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

#108

Post by jheriko »

jlgreco wrote: post #107
jheriko wrote: post #89

Earlier quoted context omitted.

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.

I don't know how to operate a airplane, but that isn't a problem I have with airplanes. That is a problem I have with myself.

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

no need to be condescending. i did just point out not knowing it was precisely my problem

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

#109

Post by ams6110 »

jlgreco wrote: post #65
ams6110 wrote: post #55

Earlier quoted context omitted.

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.

I suppose it depends on what you consider large. At the moment my team is 3 who are doing daily work, and a few more that do more intermittent work. I'd consider that to be small.

I have in the past worked on larger teams (~15 developers), that project used svn and we never seemed to really run into any issues even though we had branches for mainline dev work, and support branches for each "released" version. I'd get the occasional conflict to resolve but it generally wasn't too bad, and I get those with Git also.

I've never worked on a project where dozens or hundreds of remote developers were contributing, but I'd say that outside of a small number of high-profile open-source projects, most people don't. I understand that's what git was built for; maybe that's why all those features just seem like overkill for anything I've never worked on.

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

#110

Post by jheriko »

jammycakes wrote: post #68
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'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 a…

yes, tbh this is the first time i have heard of the reflog.

i extensively googled when i had the original problem which put me off using git

Post reply on HN