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

171–180 of 201 posts

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

#171

Post by mrtngslr »

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…

Very sensible comment :) Having gained the most mind-share is Git's best feature, along with it's flexible branches and speed. Those features are super important and as a Mercurial developer, I'm very impressed with them.

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

#172

Post by oleganza »

"The local revision numbers play no role here -- btw, they're just an (arbitrary) ordering of the commits in your local repository. No magic there."

I disagree. Mercurial is famous for its "simple" revision numbers that differ between repositories. These revision number are magical as they can suddenly change when you merge some branches and older commits get pulled into your history. Since mercurial and git are mostly about collaboration, non-stable identifiers can be very confusing.

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

#173

Post by smithzvk »

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…

> Consider filesystems, which are also tools used to manage stored data. If I'm writing some Python thing, I don't proclaim to everyone that I'm storing my work on a ReiserFS volume, and I'm thrilled by the fact that ReiserFS indexes its metadata using a B+ Tree. I just store my data.

No, but you do see thousands upon thousands of pages of text written about how to best use a shell to interface with the file system. This is what I think we are dealing with, we are on the cusp of actually having competent tools for the task of this collaborative, everybody works on their own computer but everything needs to be merged together in the end, and still work, thing that we have been doing for years. Give it a few years to settle down and either csh (Hg) or bash (Git) will win out and there will still be odd birds out there using sh (SVN) or zsh (Darcs) (feel free to permute those assignments to your taste).

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

#174

Post by venomsnake »

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…

All software has its quirks.

And it shows when you move out of the ultra comfort zone. If you want to drill a hole in the wall you need to take into consideration the size of the hole, the power of the drill and what are you drilling in. You cannot abstract them.

And then one day someone decides to use your python code not on ReiserFS but on Ext2 that has no journaling and all hell could break loose.

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

#175

Post by gecko »

oleganza wrote: post #172

"The local revision numbers play no role here -- btw, they're just an (arbitrary) ordering of the commits in your local repository. No magic there." I disagree. Mercurial is famous for its "simple" revision numbers that differ between repositories. These revision number are magical as they can suddenly change when you merge some branches and older commits get pulled into your history. Since mercurial and git are most…

They can't change in a given repo unless you use history-modifying extensions. They do differ between repos. Most modern third-party tools, including Kiln, hide them by default for this reason.

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

#176

Post by sampo »

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…

> what about Git's branches and history management is better than Mercurials with the appropriate plugins turned on?

I don't know which it better, but at least different: git has automatic garbage collection for dangling commits (after 30 days or so by default).

With Mercurial, if you want to remove dangling commits, you have to do it by hand. And if they have been pushed, you have to go to the remote repo and manually remove them there too. And everyone else who has pulled them, will need to manually remove them.

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

#177

Post by xradionut »

smithzvk wrote: post #173
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…

> Consider filesystems, which are also tools used to manage stored data. If I'm writing some Python thing, I don't proclaim to everyone that I'm storing my work on a ReiserFS volume, and I'm thrilled by the fact that ReiserFS indexes its metadata using a B+ Tree. I just store my data. No, but you do see thousands upon thousands of pages of text written about how to best use a shell to interface with the file system.…

Only one tool of each category will "win" out? That's a mighty dystopian future.

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

#178

Post by oleganza »

gecko wrote: post #175
oleganza wrote: post #172

"The local revision numbers play no role here -- btw, they're just an (arbitrary) ordering of the commits in your local repository. No magic there." I disagree. Mercurial is famous for its "simple" revision numbers that differ between repositories. These revision number are magical as they can suddenly change when you merge some branches and older commits get pulled into your history. Since mercurial and git are most…

They can't change in a given repo unless you use history-modifying extensions. They do differ between repos. Most modern third-party tools, including Kiln, hide them by default for this reason.

Thanks for clarifying this. I haven't touched mercurial for a while.

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

#179

Post by cbhl »

Part of me wonders whether this is an instance of "The Magpie Developer"[0]. I know that I personally prefer git and bzr over cvs and svn, but just ten years ago, people were all talking about how Linux had just switched to BitKeeper.

I also suspect that rather than having a bikeshed-esque argument about switching between one DVCS and another, we can come up with technical solutions to enable everyone to work together. For example, when I was interning at Facebook two years ago, git-svn was used extensively to let the rank-and-file employees work with git, while still allowing chuckr to deploy off of SVN.

For mercurial and git, there are services like Kiln Harmony[1] and hg-git, too.

[0] http://www.codinghorror.com/blog/2008/01/the-magpie-develope...

[1] https://secure.fogcreek.com/kiln/

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

#180

Post by gkya »

gbog wrote: post #135
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.

Maybe you could let git influence and hopefully improve the way you work. For instance, when refactoring something quite complex with good test coverage, you want each commit to be the smallest atomic commit that can pass all tests. But you also want to very quickly and "carelessly" add debug logs, assertions, changes in many files. For this kind of task I have found the following workflow to be very helpful and fast…

> Edit: When using `git add -p` you can even use 'e' command to manually edit your patch.

This is not something specific to git. Also, this example as a whole is nowhere near an improvement over an hg + mq workflow:

1. `hg qinit; hg qnew refactoring' to add a patchset

2. Make changes, add to patch with `hg qrefresh'

3. Run tests, if tests fail, pop a patch from the queue with `hg qpop'

4. Repeat until everything is fine, then `hg qfinish' to commit the patch to the history.

Post reply on HN