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

31–40 of 118 posts

Re: What's New in Mercurial 3.0

#31

Post by Crito »

VoiceOfWisdom wrote: post #13
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.

Exactly! The fact that Git allows you to destructively rewrite history public history is EVIL. Not every user of revision control is going to have a Phd in Not Fucking Up The Repo and I never want a situation like the Jenkins devs had[1] to occur with my projects. [1] https://news.ycombinator.com/item?id=6713742

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

Re: What's New in Mercurial 3.0

#32

Post by Crito »

gizmogwai wrote: post #12
bru wrote: post #8

Earlier quoted context omitted.

Could you explain this difference to a git user?

In git, when you rewrite your history, the old version is gone (well, you still have the revlog for 30 days, but then it's basically over). This is why some commands like `git push --force`after a rebase can cause so much hassle to a community (hello Jenkins!) Here, the principle is te keep all the history, and its rewrites, forever, and to ease the distribution of those changesets.

Nitpick: The old version will not be gone unless it is no longer reachable from any of the refs. Making it no longer reachable from merely one of many refs will not cause it to be GC'd.

This isn't really a nitpick though, since this means that similar porcelain could be implemented on top of git fairly easily. The underlying data-model supports it.

Re: What's New in Mercurial 3.0

#33

Post by laureny »

scott_karana wrote: post #4
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 agree. The "alternative universes" that Git creates after rebases are hard to deal with once branches are published anywhere .

Which is why every single tutorial of rebase you can find will explain that you should never rebase branches that have already been published.

Re: What's New in Mercurial 3.0

#35

Post by gecko »

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 objectively correct. For example, "git checkout foo" might mean go to the foo branch, or might mean revert a file called "foo". There is no way to know. If you want to be sure to revert a file called foo, you can do "git checkout -- foo", I believe, but I don't know a branch equivalent (and it at any rate won't be symmetrical). Want to create a new branch? That's "git checkout -b newbranch". Want to delete it? That's "git branch -d newbranch". There are tons of things like this in the Git UI, where commands have basically arbitrary parameters in different contexts.

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. I really, profoundly wish that had actually panned out. Instead, Git's low-level commands gradually grew more user-friendly until it hit the "good enough" zone. That's what people usually mean when they say Git's complicated.

Re: What's New in Mercurial 3.0

#37

Post by anton_gogolev »

philtar wrote: post #34

Can someone explain why the push in the example (that people familiar with hg would recognize) failed?

There are a couple of settings in repository-level configuration file which tell Mercurial where to pull from (`default`) and where to push to (`default-push` or `default`; think "remotes" in Git parlance):

    [paths]
    default = http://live.hglabhq.com/hg/hgsharp/hgsharp
    default-push = http://live.hglabhq.com/hg/hgsharp/hgsharp
When you create a new repository with `hg init`, the `[paths]` section is, naturally, empty, hence the complaining.

Re: What's New in Mercurial 3.0

#38

Post by davvid »

Crito wrote: post #31
VoiceOfWisdom wrote: post #13

Earlier quoted context omitted.

Exactly! The fact that Git allows you to destructively rewrite history public history is EVIL. Not every user of revision control is going to have a Phd in Not Fucking Up The Repo and I never want a situation like the Jenkins devs had[1] to occur with my projects. [1] https://news.ycombinator.com/item?id=6713742

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

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

Re: What's New in Mercurial 3.0

#39

Post by anton_gogolev »

davvid wrote: post #38
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.

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?

Re: What's New in Mercurial 3.0

#40

Post by ColdHawaiian »

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).
Post reply on HN