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

91–100 of 118 posts

Re: What's New in Mercurial 3.0

#91

Post by rkwz »

gecko wrote: post #35
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…

There are two things people mean when they say Git is complicated. Some people mean that Git's model is complicated, which what you're talking about. I actually find its model very simple, some people find it complicated, but at any rate, I certainly think Git and Mercurial have comparable complexity in the model. What most people mean, though, is that Git's UI is complicated. To be blunt, I think this is simply obje…

> Way back when Git was first created, the plan was for what is now called Git to be the underlying implementation of a higher-level UI.

Has anyone attempted to actually implement this? Building a 'VCS' on top of git but with a simple 'UI'?

Re: What's New in Mercurial 3.0

#92

Post by rkwz »

edavis wrote: post #51
jordigh wrote: post #45

Earlier quoted context omitted.

> This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model. Making people understand the internal data structures in order to understand a UI is... not good.

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, backward, parking etc and that's what most car drivers care about.

Re: What's New in Mercurial 3.0

#93

Post by Locke1689 »

colechristensen wrote: post #56
tomlu wrote: post #55

I feel like Mercurial still has a chance to become a real force if it can provably solve some of the real issues with git. It won't do to just have a nicer CLI since most people are used to git by now. Here are some of git's real problems: * Performance issues with multi-GB git repos * Handling of large binary files * Submodules - Mercurial has subrepos, but I don't know how they compare

There is opportunity for a powerful tool to handle the very common bad practice of including giant binary blobs which don't belong in version control. I'd like to see a second class of files which are only checksummed (or timestamped) on 'status', 'diff', 'add' and then binary-diffed on commit for possible compression (or perhaps deduped with checksums of blocks) with features like 'git/hg binary-add somefile.jar' to…

There is opportunity for a powerful tool to handle the very common bad practice of including giant binary blobs which don't belong in version control.

It's only a bad practice because our tools don't support it properly.

There seems no reasonable argument that there is some predefined size limit that all assets in version control must, by natural law, fall under.

The criteria I have for version controlled assets is they must 1) be versionable, 2) have a comparison tool, and 3) be strongly connected to the other assets under control.

Re: What's New in Mercurial 3.0

#94

Post by skrause »

rkwz wrote: post #91
gecko wrote: post #35

Earlier quoted context omitted.

There are two things people mean when they say Git is complicated. Some people mean that Git's model is complicated, which what you're talking about. I actually find its model very simple, some people find it complicated, but at any rate, I certainly think Git and Mercurial have comparable complexity in the model. What most people mean, though, is that Git's UI is complicated. To be blunt, I think this is simply obje…

> Way back when Git was first created, the plan was for what is now called Git to be the underlying implementation of a higher-level UI. Has anyone attempted to actually implement this? Building a 'VCS' on top of git but with a simple 'UI'?

http://en.wikipedia.org/wiki/Cogito_(software)

Re: What's New in Mercurial 3.0

#95

Post by gammarator »

rkwz wrote: post #91
gecko wrote: post #35

Earlier quoted context omitted.

There are two things people mean when they say Git is complicated. Some people mean that Git's model is complicated, which what you're talking about. I actually find its model very simple, some people find it complicated, but at any rate, I certainly think Git and Mercurial have comparable complexity in the model. What most people mean, though, is that Git's UI is complicated. To be blunt, I think this is simply obje…

> Way back when Git was first created, the plan was for what is now called Git to be the underlying implementation of a higher-level UI. Has anyone attempted to actually implement this? Building a 'VCS' on top of git but with a simple 'UI'?

EasyGit, and others: https://people.gnome.org/~newren/eg/

Re: What's New in Mercurial 3.0

#96

Post by ngoldbaum »

bobmoretti wrote: post #63
ngoldbaum wrote: post #19

Earlier quoted context omitted.

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.

The advantage of changeset evolution is obvious to me. But as a longtime Mercurial user, I don't grok the benefit of bookmarks. Do you have a simple example where a bookmark is more useful than a permanent branch?

The teams I work with don't like the permanence of mercurial named branches. Bookmarks are a nice lightweight alternative way to name a short-lived head rather than creating a permanent tag for a two-line commit. Before bookmarks we used anonymous heads.

Re: What's New in Mercurial 3.0

#97

Post by gammarator »

asimov42 wrote: post #79
EGreg wrote: post #6

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

I definitely prefer hg but github has pretty much won war so I'm stuck with git. At the end of the day I'm not going to get religious about version control, I have vim for that :)

The hg-git plugin for mercurial actually makes working with github from hg quite smooth, although I admit my workflows are fairly straightforward.

https://hg-git.github.io/

Re: What's New in Mercurial 3.0

#98

Post by mhw »

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…

It's not all that helpful to compare version control tools with cars, I don't think. Users of a version control tool do need to know about branches, tags, commits and such because they are the heart of what version control is. If you've ever seen an environment where version control tooling has been introduced without the support of the developers you'll have seen what happens when you treat it like a car: empty check in messages, commits getting clobbered by "I'll jut check in my version" merges, and contention over file locks in tools where locking was part of the model.

Re: What's New in Mercurial 3.0

#100

Post by whatevsbro »

edavis wrote: post #51
jordigh wrote: post #45

Earlier quoted context omitted.

> This is why people say you need to understand the underlying model of git to grok it. The commands make perfect sense from the perspective of the data model. Making people understand the internal data structures in order to understand a UI is... not good.

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.

Do you want to understand exactly how a car works, or do you just want to go places?
Post reply on HN