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

71–80 of 118 posts

Re: What's New in Mercurial 3.0

#71

Post by pfranz »

tieTYT wrote: post #52
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…

Your complaints seem like a very indirect way to get what you want. Perhaps it's git's fault for making these possibilities, but I didn't even know they exist. If you want to revert/reset a file, why don't you just use the reset command? That seems like a more direct way than using checkout. If you want to create a new branch, why not use "git branch branch-name"? As another said, the "git checkout -b branch-name" is…

"If you want to revert/reset a file, why don't you just use the reset command? That seems like a more direct way than using checkout."

Because that's what git tell you to do when you run "git status"

# (use "git checkout -- ..." to discard changes in working directory)

Re: What's New in Mercurial 3.0

#72

Post by SoftwareMaven »

JoshTriplett wrote: post #62
SoftwareMaven wrote: post #57

Earlier quoted context omitted.

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?

Oracle Ksplice[1]: patches the kernel with security updates without rebooting.

1. http://www.ksplice.com/

Re: What's New in Mercurial 3.0

#73

Post by gecko »

tieTYT wrote: post #52
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…

Your complaints seem like a very indirect way to get what you want. Perhaps it's git's fault for making these possibilities, but I didn't even know they exist. If you want to revert/reset a file, why don't you just use the reset command? That seems like a more direct way than using checkout. If you want to create a new branch, why not use "git branch branch-name"? As another said, the "git checkout -b branch-name" is…

Interesting you should mention "git reset", because, depending on the options you give it, it either:

  * reverts one file
  * reverts all files
  * removes changes from the index, but doesn't otherwise change anything at all
  * moves your branch, without changing any files
  * moves your branch and changes all files
This rather makes my point.

"git checkout -b", meanwhile, is not a shorthand for "git branch something", but rather "git branch --track something origin/something", unless there is no "origin/something", in which case you are again correct.

Re: What's New in Mercurial 3.0

#74

Post by sampo »

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…

> "the plan was for what is now called Git to be the underlying implementation of a higher-level UI"

Some time around year 1960, the plan was to develop a language with syntax ("M-expressions") on top of the Lisp S-expressions.

We are still waiting, I guess.

http://www-formal.stanford.edu/jmc/history/lisp/node3.html

Re: What's New in Mercurial 3.0

#75

Post by novaleaf »

kyrra wrote: post #65
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

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.

Re: What's New in Mercurial 3.0

#76

Post by ngoldbaum »

merijnv wrote: post #66
JoshTriplett wrote: post #61

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

Not only that, but outdated changes aren't shared by clone or pull unless you explicitly ask for them. The full history stays on the server but intermediate commits slowly fade away as users hardly ever pull them.

Re: What's New in Mercurial 3.0

#77

Post by tsm »

anton_gogolev wrote: post #39
davvid wrote: post #38

Earlier quoted context omitted.

It's also the default these days. $ git init --bare --shared foo.git Initialized empty shared Git repository in foo.git/ $ cat foo.git/config # ... [receive] denyNonFastforwards = true

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

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

Re: What's New in Mercurial 3.0

#78

Post by wtallis »

tomlu wrote: post #64
colechristensen wrote: post #56

Earlier quoted context omitted.

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.

Usually, you can build the game without them, up to the final packaging stage. Almost any game that is built on an engine can have all of the asset files swapped out without having to recompile anything, and as long as the file format and structure for assets is relatively stable there doesn't have to be a tight coupling between engine versions and asset versions except when doing QA and benchmarking.

This is one of the cases where git's inability to handle rewriting a public history is a pain. The art and programming departments should be able to develop along separate branches, and the programmers should be able to pull a tree from art that has everything between tags squashed (but in a reversible fashion in case there's a need to bisect something later).

Re: What's New in Mercurial 3.0

#79

Post by asimov42 »

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 :)

Re: What's New in Mercurial 3.0

#80

Post by tomlu »

sherlockmao wrote: post #70
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

Those are interesting, and git has some similar large file extensions too. However during some years of experimentation I have become convinced that these features have to be part of core or they will always be second-rate citizens and not work well in practice.
Post reply on HN