Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's New in Mercurial 3.0

hglabhq.com

Post reply on HN
Print view View original

101–110 of 118 posts

Re: What's New in Mercurial 3.0

#101

Post by __david__ »

rkwz wrote: post #92
edavis wrote: post #51

Earlier quoted context omitted.

See, but I don't think they're "internal" at all. The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git.

> The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git. Users don't need to know the 'very essence' of a tool inorder to use it. Do you think that people who drive cars know in detail about how car works? They just need to know about starting a car, making it go forward…

You don't have to understand how a carburetor works to drive a car, but you do have to know that "Drive" connects the engine to the wheels.

Git is like driving a manual transmission. In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general. It's not rocket science and most people can pick it up.

Re: What's New in Mercurial 3.0

#102

Post by timv »

tsm wrote: post #77
anton_gogolev wrote: post #39

Earlier quoted context omitted.

I love just how persistent is Git in confusing users. Double negative, anyone?

It's not a double negative...denying non-FFs != allowing FFs.

The positive statement would be "onlyFastForwardMerges=true" or "mergesMustBeFastForward=true"

Re: What's New in Mercurial 3.0

#103

Post by phaemon »

rkwz wrote: post #92
edavis wrote: post #51

Earlier quoted context omitted.

See, but I don't think they're "internal" at all. The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git.

> The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git. Users don't need to know the 'very essence' of a tool inorder to use it. Do you think that people who drive cars know in detail about how car works? They just need to know about starting a car, making it go forward…

> Do you think that people who drive cars know in detail about how car works?

I think professional drivers do indeed know how their car works. They certainly should.

We are talking about professional developers/programmers/devops here, right?

Re: What's New in Mercurial 3.0

#104

Post by masklinn »

__david__ wrote: post #101
rkwz wrote: post #92

Earlier quoted context omitted.

> The "underlying model of git" that David refers to (blobs, trees, commits, tags, branches, HEAD, etc.) aren't seen as internal data structures to be glossed over by a UI. They're the very essence of git. Users don't need to know the 'very essence' of a tool inorder to use it. Do you think that people who drive cars know in detail about how car works? They just need to know about starting a car, making it go forward…

You don't have to understand how a carburetor works to drive a car, but you do have to know that "Drive" connects the engine to the wheels. Git is like driving a manual transmission. In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general. It's not rocket science and most people can pick it up.

> Git is like driving a manual transmission.

Git is nothing like driving manual.

> In a manual car you have to understand that the clutch disengages the motor from the drive shaft and how the different gears work in general.

No, you most definitely don't, that's complete lunacy. The vast majority of (manual) drivers[0] have no idea how things work and they don't give a fuck. Different gears are for "go faster" and "go slower", and the clutch is for "change gear". People learn to do it right because the alternative is to stall or get a horrible grinding sound and pay top bucks to get stuff fixed, not because they understand how things work under the hood.

[0] in countries where it's the norm, not in countries like the US where manual is for nerds and passioned

Re: What's New in Mercurial 3.0

#105

Post by mrtngslr »

novaleaf wrote: post #75
kyrra wrote: post #65

Earlier quoted context omitted.

Mercurial has the LargeFiles extension[0]. This ships with Mercurial by default, just disabled. This does help some. [0] http://mercurial.selenic.com/wiki/LargefilesExtension

while i like LargeFiles, it's really not enough. Support for binary content (and indeed, history truncation) needs to be native. As it stands, LargeFiles can only be used on intranet networks, and if you've ever used it for any serious purpose, you'll run into corruption. It's really disappointing to see 3.0 announced with no solution to this.

Largefiles are being used for production in game companies and we have not gotten reports about corruption.

Re: What's New in Mercurial 3.0

#106

Post by mrtngslr »

ColdHawaiian wrote: post #40
wirrbel wrote: post #21

While a lot of tutorials mention how complicated git is in contrast to mercurial I - being a git native - feel the other way around. Git is intuitive with a small number of concepts necessarry to grasp my whole workflow. Using this workflow with mercurial is really frustrating when I do it - the occasional pull request for a python-based project. A git branch as a concept is really simple, the mercurial ways I just c…

The key concept that you need to truly understand how Git works is to just remember that Git is just a tree of commits, with temporary and movable Post-it notes attached. (The Post-it notes representing branches and other references).

That's a good image. The key difference to Mercurial is then that Mercurial's tree of commits don't need Post-it notes. The tree can stand on its own without extra branch labels. You can add them (see bookmarks) but they're an optional feature.

Re: What's New in Mercurial 3.0

#108

Post by mrtngslr »

ngoldbaum wrote: post #19
EGreg wrote: post #6

Changeset evolution puts mercurial slightly ahead of git here Now if only Atlassian's bitbucket was as popular as github!

Sadly bitbucket does not have very good support for features from "modern" mercurial like bookmarks and changeset evolution. Since most of their users are git users I don't think they are strongly motivated to shore up mercurial support.

If you haven't already, then you can go vote on this issue: https://bitbucket.org/site/master/issue/6710/enable-exchange... -- and ask your collegues to do so too! :-)

The Bitbucket devs are nice guys and have said that they do listen to issue feedback like this.

Re: What's New in Mercurial 3.0

#110

Post by mrtngslr »

bru wrote: post #8
krallja wrote: post #3

Earlier quoted context omitted.

I'm excited because it is SO MUCH more powerful than git's commit history rewriting, because "I re-wrote history" becomes part of your (distributed) repository's history.

Could you explain this difference to a git user?

From: https://plus.google.com/+MartinGeisler/posts/eR6obsGwTGw

Changeset evolution has some similarities with a distributed reflog. Like Git, commits are immutable in Mercurial and we can only "change" a commit by creating a new version and then hide the old version. Mercurial "hides" the old version today by stripping it from the repository — the old version is then stored in a bundle in the .hg/strip-backups folder.

This is far from optimal, so a first step was to add a concept of hidden commits. Hidden changesets have been part of core Mercurial for some time now. The evolve extension enables it and actually changes commands to use it. So "hg commit --amend" will normally strip the old commit, but when evolve is enabled, it will instead hide it. This is both faster and safer.

The next step is the introduction obsolete markers. These are small markers that tell you when a commit is succeeded by a better version. When you amend a commit, an obsolete marker will be created that say "the new version obsoleted the old version". This information is something that Git doesn't store, and it is by distributing these markers that we can make Mercurial more intelligent. As an example, if I amend a commit that you have already based work on, then evolve will know that it should rebase your work onto the successor I created. It will tell you about this when you pull from me and get the new version along with the obsolete marker. Your commits will be called "unstable" as that point, meaning that they are descendants of a commit marked obsolete (they descend from the commit I amended and thus marked obsolete). You can run "hg evolve" and it will figure out that it should run "hg rebase" behind the scenes.

Seen like this, I would say evolve is similar to what happens in Git when you edit history, but with some extra meta data that will allow you to edit shared history with confidence.

Post reply on HN