Mercurial developer responds to "Switch to git?" • Hacker News Board

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

#111

Post by jheriko » Mon, Nov 18, 2013, 4:59 AM UTC

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…

yeah, as a rule a user shouldn't care about implementation details. to be fair this is mainly possible with git in my experience... but not always. my experience with hg has been positive in that regard

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

#112

Post by jlgreco » Mon, Nov 18, 2013, 5:07 AM UTC

functional_test wrote: post #106

steveklabnik wrote: post #81

Earlier quoted context omitted.

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?

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

When you rebase, commits are not lost. If there is a ref pointing at them then they will continue to stick around. If there isn't then the next time that gc is run they would be removed.

The solution to what you are looking for is to precede each rebase with a command to 'anchor' the current commit under a custom ref. If you wanted to look back in time, you'd use a corresponding command. This is all, say, 20 lines of shell, primarily using the git plumbing..

Of course this is just recreating a permanent reflog-work-alike, reflog of course already having this usecase covered for individual devs working on their machines...

If it is the other usecase of rebasing, rebasing public code, say on a centralized repo or the repo of your build fleet, that has you concerned, then instead of just set a policy of only permitting fast-forward commits in those cases. That is a reasonable thing to do, it is a legitimate workflow that git supports. There is no reason that you cannot keep auditable logs of exactly what has been going on with your git repo.

I think people hear "rewrites history" and let their imaginations run wild with sci-fi tales of wonder, only then to think of the grave horrors such power would enable... but forget to look at what actually is happening when you "rewrite history" in git. There is no reason to fear it.

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

#113

Post by JoshTriplett » Mon, Nov 18, 2013, 5:10 AM UTC

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.

Even if you do run git gc, by default git will still keep the reflog and all objects reachable from it around for 30 days.

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

#114

Post by jlgreco » Mon, Nov 18, 2013, 5:12 AM UTC

ams6110 wrote: post #109

jlgreco wrote: post #65

Earlier quoted context omitted.

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…

I guess 'large' is really a function of number of developers and rate and diversity of commits. I've been in a few situations where two or three of us were putting out several changes to the same piece of code rapidly (typically to meet a deadline). Git has proven invaluable in untangling some of the knots we've put ourselves into in those sorts of situations. If commits are coming in slowly, with plenty of notice, and everyone is working on different parts of the codebase, then you probably won't need to do much fancy stuff very often.

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

#115

Post by jlgreco » Mon, Nov 18, 2013, 5:13 AM UTC

jheriko wrote: post #108

jlgreco wrote: post #107

Earlier quoted context omitted.

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

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

#116

Post by wbl » Mon, Nov 18, 2013, 5:17 AM UTC

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…

Why bother? Even if the history of some off-branch is messy as heck, it can be summed up in the merge anyway.

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

#117

Post by ajross » Mon, Nov 18, 2013, 5:18 AM UTC

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…

This is true, but seems specious. By this definition (development tools that can irrecoverably destroy data in the working directory) you should be flaming against vim too, not to mention rm or the dreaded "clean" target to make.

It just seems silly, sorry. And while I know little about hg I suspect it's not even true: hg will never delete a file it doesn't understand? What about the equivalent of git clean (which I use daily -- it's loss would be a minor hardship and definitely not an advantage for mercurial)?

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

#118

Post by bgrainger » Mon, Nov 18, 2013, 5:21 AM UTC

voltagex_ wrote: post #50

w0rd-driven wrote: post #47

Earlier quoted context omitted.

SourceTree is good if you can handle the .NET 4.5 requirement. At work, we can't risk the breakage 4.5 can possibly do to 4.0 apps and can't force customers to upgrade for 2/x applications so I don't bother. My first foray into DVCS was Mercurial through Kiln and subsequently TortoiseHg. It's always been great but the introduction of the workbench made everything gel. Having all of the UI in one spot made the experie…

Have you tested 4.5? What breaks?

A significant problem is that once .NET 4.5 is installed, a developer can no longer test how an app behaves under .NET 4, even if the app still has its target framework set to .NET 4.

There are several major WPF bugs fixed in .NET 4.5; developers will no longer encounter those bugs locally, but can only find them on a dedicated .NET 4 testing machine, or (more likely) reported from a .NET 4 customer in the field.

There's a detailed writeup of the problem here: http://social.msdn.microsoft.com/Forums/vstudio/en-US/c05a8c...

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

#119

Post by jlgreco » Mon, Nov 18, 2013, 5:23 AM UTC

ajross wrote: post #117

jlgreco wrote: post #45

Earlier quoted context omitted.

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…

This is true, but seems specious. By this definition (development tools that can irrecoverably destroy data in the working directory) you should be flaming against vim too, not to mention rm or the dreaded "clean" target to make. It just seems silly, sorry. And while I know little about hg I suspect it's not even true: hg will never delete a file it doesn't understand? What about the equivalent of git clean (which I…

https://news.ycombinator.com/item?id=6752077

Understand that I am very pro-git. I'm just trying to be precise here.

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

#120

Post by thaumasiotes » Mon, Nov 18, 2013, 5:37 AM UTC

jlgreco wrote: post #57

ggchappell wrote: post #52

Earlier quoted context omitted.

That's an interesting point. Here are my off-the-top-of-my-head thoughts: I guess the real goal is proper separation of responsibilities. When I cook a meal, I use devices that run on electricity. I want to be able to power them up by plugging them in without thinking much about it. The people who work at my power company need to think about the intricacies of generating and transmitting electricity, but I don't want…

Even when powering electronics in the home, you have to worry about which sort of power the device needs. Does it need a great big 240V AC outlet, or just the regular 120V AC (using American values...)? Is the device DC powered instead? Does it have it's own wall-wart, or can you use a AC->USB converter? Does it use USB micro or mini? These are things the consumer has to worry about. Of course in practice "worry abou…

> Even when powering electronics in the home, you have to worry about which sort of power the device needs. Does it need a great big 240V AC outlet, or just the regular 120V AC (using American values...)?

This isn't accurate as to the electronics that I use. All the adapters say "input 120 - 240V". Non-portable electronics tend to be compatible with the plugs in the same area where you buy them... since they're not portable.