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

61–70 of 118 posts

Re: What's New in Mercurial 3.0

#61

Post by JoshTriplett »

krallja wrote: post #3
VoiceOfWisdom wrote: post #2

I am so excited for Changset Evolution. The only thing I miss having from git in mercurial, is the ability to safely rewrite commit history.

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.

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

That can be a feature or a bug.

This would be wildly useful for a public branch that needs periodic rebasing, because unlike a git rebased branch, you'd have a history of the rewrites.

On the other hand, most users who locally use git rebase -i to transform a local series of WIP patches into a sensible patch series for submission do not want any record of the intermediate commits (which may not bisect, or even build, and which may have commit messages like "WIP: try fixing it again"). git makes it easy and sensible to commit early and often, and then sort out a sensible patch series from the result.

Re: What's New in Mercurial 3.0

#62

Post by JoshTriplett »

SoftwareMaven wrote: post #57
Crito wrote: post #31

Earlier quoted context omitted.

"Git", (really, whatever git server you are using for your publicly accessible repo) only allows you to do that if you allow it to allow you to do that. Rejecting non-fast-forward commits is standard practice in every git shop that I've worked in.

We use git rewriting extensively and do allow non-FF commits. We also have process and tools in place such that master is held sacred (and our live branch is untouchable). Every once in a blue moon, a master branch will get a non-FF, and our tooling is such that we make sure everyone knows it happened. However, we are a small team consisting of mostly Linux kernel developers, so that may influence the level of trust…

> However, we are a small team consisting of mostly Linux kernel developers

What team is that, and what are you working on?

Re: What's New in Mercurial 3.0

#63

Post by bobmoretti »

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.

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?

Re: What's New in Mercurial 3.0

#64

Post by tomlu »

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

Why do you say it's bad practice? Game assets come to mind, these aren't derived artifacts and you can't build the game without them.

Re: What's New in Mercurial 3.0

#65

Post by kyrra »

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

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

Re: What's New in Mercurial 3.0

#66

Post by merijnv »

JoshTriplett wrote: post #61
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.

> 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. That can be a feature or a bug. This would be wildly useful for a public branch that needs periodic rebasing, because unlike a git rebased branch, you'd have a history of the rewrites. On the other hand, most users who locally use git rebase -i to…

This is of course a straw man as Mercurial already has several tools for this (MQ, rebase, histedit), which will keep working as-is even with changeset evolution. So changeset evolution allows things in addition to the local rebasing.

Re: What's New in Mercurial 3.0

#67

Post by __david__ »

jordigh wrote: post #47
__david__ wrote: post #44

Earlier quoted context omitted.

I was impressed and excited when I read about that feature, but as I chewed on it for a while I realized I don't think I would ever use it. Most of my history rewriting is done locally before I've ever pushed—in that case I don't want those kept track of because they are throwaway (the same reason I don't check in a file after every single character change). For the case when you want to push out to the world… Well,…

>Most of my history rewriting is done locally before I've ever pushed That's just a habit you acquired because right now rewriting public history is a "problem". It shouldn't be a problem. In fact, it's something people do, e.g. how about being able to edit a pull request as it's being discussed and it being ok if that pull request gets merged as it's being discussed?

Perhaps, but I think it's more fundamental than that. Like I said earlier, I don't save after ever character or word typed into a file, and I don't even commit changes until I think they might be ready. I don't push until it works (for some definition of "works" depending on how lazy I am and what project it is).

There are all these different levels of "saveyness" and the lower levels are just not as interesting.

In particular, I don't want stupid untested typos in the commit history because they just aren't interesting or helpful.

But I'm willing to say that I'm probably missing something… I just don't see what it is yet. :-)

Re: What's New in Mercurial 3.0

#68

Post by CyberShadow »

jordigh wrote: post #14
CyberShadow wrote: post #7

Earlier quoted context omitted.

Technically git has this too, although not in a very user-friendly form: http://git-scm.com/blog/2010/03/17/replace.html It requires some manual setup on all checkouts for the changes to propagate automatically.

This is not the same. Well, it's sort of the same infrastructure, but it would require a lot of work to actually work like hg evolve. With Evolve, there is something similar to .git/refs/replace, called obsolescence markers, which may or may not indicate which commit replaces the obsolete commit (some commits are replaced, others are just pruned). These markers are created automatically every time you rewrite history…

> It doesn't seem to me like git replace can work over the wire?

I thought that being in the /refs/ namespace would make them eligible for easy synchronization once set up, but on second thought it doesn't seem like it. Git examines parents of refs to determine when something needs to be updated, but would use the parent of the object replacement in this case.

I think a mechanism similar to "git notes" would be better, where the ref points to a history of commits with each tree containing files for each replaced object. I've hacked git to do this at one point so we could retroactively edit git commit messages, but abandoned the effort after discovering "git notes".

Re: What's New in Mercurial 3.0

#69

Post by nnethercote »

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…

> Git is intuitive with a small number of concepts necessarry to grasp my whole workflow.

http://jordi.inversethought.com/blog/on-gitology/ explains git's complexity extremely well (without even getting into horribleness of the command line UI). The following is a key quote, though you should read the whole thing.

The following gitological concepts are not particular to git:

* repositories (repos)

* commits or changesets (csets)

* directed acyclic graph (DAG)

* branches

* pushing and pulling changes

* whole-repo tracking, not individual files

* rebasing csets

* pushing and pulling csets

The following are purely gitological and add unnecessary complexity, in addition to eventually being unavoidable:

* Exposing the index/staging area

* Exposing other implementation details: blobs, trees, commits, refs

* refs and refspecs

* Branches are refs

* Detached HEADs (a.k.a “not on a branch”)

* Distinguishing remote and local tracking branches

* Choosing which branch to pull onto

* Bare repos

* Hard, soft, mixed resets

* Porcelain vs plumbing

Re: What's New in Mercurial 3.0

#70

Post by sherlockmao »

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

Facebook's hgwatchman and remotefilelog extensions; largefiles
Post reply on HN