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

51–60 of 118 posts

Re: What's New in Mercurial 3.0

#51

Post by edavis »

jordigh wrote: post #45
__david__ wrote: post #43

Earlier quoted context omitted.

I feel that people that rail on "git checkout" don't actually understand what it does. It does two things: 1) unpacks files from the repository into the working directory, and 2) updates the current working branch. Want to revert your changes? That's unpacking from the repo to the working dir. Want to switch to a different branch? That's also unpacking files from the repo to the working dir. The only difference is th…

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

Re: What's New in Mercurial 3.0

#52

Post by tieTYT »

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…

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 just shorthand for convenience.

I've been learning git over a mere 2 months (I came from svn), I'm finding its UI to be very pleasant.

As someone else said, that index/staging/cached situation is bad, though.

Re: What's New in Mercurial 3.0

#53

Post by barrkel »

__david__ wrote: post #43
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…

I feel that people that rail on "git checkout" don't actually understand what it does. It does two things: 1) unpacks files from the repository into the working directory, and 2) updates the current working branch. Want to revert your changes? That's unpacking from the repo to the working dir. Want to switch to a different branch? That's also unpacking files from the repo to the working dir. The only difference is th…

The thing I find unpleasant with git is the inconsistency of commands. Why git branch -d for deleting branches, but git remote rm for deleting remotes? Etc.

As to git's basic model - a dag of commits, with branches being little more than auto-updating labels for commits - that fit into place in the first 5 minutes of usage. My learning time with git was shorter than any previous source control I used, except for sourcesafe, in so far as that is a SCM.

Re: What's New in Mercurial 3.0

#54

Post by russelldavis »

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 branch equivalent is `git checkout foo --`. I wrote a simple shell script[1] that makes that the default, requiring you to do `-- ` for files, so there's never a possibility of ambiguity.

[1] https://gist.github.com/russelldavis/e5173ce1269fae67baaf

Re: What's New in Mercurial 3.0

#55

Post by tomlu »

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

Re: What's New in Mercurial 3.0

#56

Post by colechristensen »

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

Re: What's New in Mercurial 3.0

#57

Post by SoftwareMaven »

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.

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 we put in not screwing things up. We also work pretty much independently; were that not the case, this would get ugly.

Re: What's New in Mercurial 3.0

#58

Post by mintplant »

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…

Check out git-annex: https://git-annex.branchable.com/how_it_works/

It operates under a similar principle (committing hashes rather than file contents) but stores the actual file contents elsewhere rather than using a compression/deduplication within the repo itself.

Re: What's New in Mercurial 3.0

#59

Post by colechristensen »

mintplant wrote: post #58
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…

Check out git-annex: https://git-annex.branchable.com/how_it_works/ It operates under a similar principle (committing hashes rather than file contents) but stores the actual file contents elsewhere rather than using a compression/deduplication within the repo itself.

I have.

It's neat, but it's more about replacing something like Dropbox than it is replacing git (despite being based on git). It also isn't particularly stable, though I have nothing but respect for the developer.

Re: What's New in Mercurial 3.0

#60

Post by AceJohnny2 »

colechristensen wrote: post #59
mintplant wrote: post #58

Earlier quoted context omitted.

Check out git-annex: https://git-annex.branchable.com/how_it_works/ It operates under a similar principle (committing hashes rather than file contents) but stores the actual file contents elsewhere rather than using a compression/deduplication within the repo itself.

I have. It's neat, but it's more about replacing something like Dropbox than it is replacing git (despite being based on git). It also isn't particularly stable, though I have nothing but respect for the developer.

As I understand it, it became something to replace Dropbox after Joey realized that git-annex's task of distributed storage of large files intersected with the Dropbox use-case, but it didn't start that way, and IMHO doesn't exclude the parent's suggestion.

I backed Joey's kickstarter, but to my shame I have yet to give git-annex-assistant a spin.

Post reply on HN