Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I kind of killed Mercurial at Mozilla

glandium.org

Post reply on HN
Print view View original

211–220 of 250 posts

Re: I kind of killed Mercurial at Mozilla

#211

Post by culebron21 »

ilostmymangoman wrote: post #208
culebron21 wrote: post #173

Earlier quoted context omitted.

Despite having 14 years of experience with Git, I still can't use it without Stackoverflow for any non-daily task. And I've read the internals back in 2008 and understand this, but it doesn't make it any clear how merges, conflict resolution, or amendments to commits work. Absolutely confusing. In Mecrurial a lot more stuff is clear and easy to remember. Example: I tried rebasing or merging, and got merge conflicts.…

When conflicts occur when performing rebase, git prints out the following: ``` hint: Resolve all conflicts manually, mark them as resolved with hint: "git add/rm ", then run "git rebase --continue". hint: You can instead skip this commit: run "git rebase --skip". hint: To abort and get back to the state before "git rebase", run "git rebase --abort". ``` The options on how to proceed seem pretty clear to me.

This is just one of a dozen unclear cases, that arise sometimes in git workflow. I do recall the first sentence in the hint, and I could have read the end too, but it's not clear, why it's "rebase --abort", not "reset --hard", that's why it's easy to forget this and other commands.

Also, "git add/rm" is confusing, because they're not opposite of each other -- 'add' puts the file to the stage area, but rm removes it and makes forget.

Re: I kind of killed Mercurial at Mozilla

#212

Post by steveklabnik »

globular-toast wrote: post #162
steveklabnik wrote: post #25

Earlier quoted context omitted.

I know people who express similar feelings. Usually it is shorthand for "I would prefer stacked diffs" or similar. Two blog posts I've seen people point at: * https://mitchellh.com/writing/github-changesets * https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/

What are these people talking about? What's the difference between "stacked diffs" and just adding commits to a branch? Who cares if the branch is called "master" or not? You could also force push updated commits (e.g. after fixup and rebase etc) and tools like Gitlab and GitHub can show you the diff between versions (or "changesets", as they call them). Gitlab at least makes it pretty clear when a change has been ma…

As I alluded to, it’s their opinion, not mine. I don’t fully understand the differences myself. But they’re very passionate about this.

Re: I kind of killed Mercurial at Mozilla

#213

Post by capitainenemo »

IshKebab wrote: post #149
wsc981 wrote: post #108

I don't understand why so many people seem to dislike git. But maybe in actuality it is not many people, as usually people who are discontent are the loudest. I used Mercurial in the past for a bit, and it was fine. But for me it doesn't seem to have any huge advantages over git, if any. And after so many years of experience using git, I know what workflows work well, how to resolve merge conflicts, how to revert to…

Aside from the terrible UI that several other people have mentioned, there are some other things that Git does badly (though I don't know if Mercurial does better): * Large projects. It has poor monorepo support (especially on Linux), and also poor multirepos support (submodules are really buggy). * Large files. LFS is a PoC-level hack; not a proper solution. * Conflict resolution. The default diff algorithm is very…

I definitely feel the large file support in Mercurial is less bolted-on. My personal favourite mercurial gui features that I hope make it into git or a mercurial using a git data store are:

  phases
  revsets (query language for revisions, they also have filesets for the files)
  hg grep --diff
  hg fa --deleted
  hg absorb

Re: I kind of killed Mercurial at Mozilla

#214

Post by meindnoch »

guenthert wrote: post #174
acdha wrote: post #117

Earlier quoted context omitted.

Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage). There’s a meme that Git is hard to use but I think it’s conflating…

> There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all Not sure about that. Git certainly doesn't make it easier by idiosyncratic use of terms and behavior. Why does 'pull' imply 'checkout'?

>Why does 'pull' imply 'checkout'?

???

It doesn't.

Re: I kind of killed Mercurial at Mozilla

#215

Post by pfranz »

acdha wrote: post #117
dehrmann wrote: post #98

Earlier quoted context omitted.

> It's just the network effect It's almost like qwerty vs dvorak in that regard, except git and mercurial were contemporaries. Mercurial isn't quite good enough to displace git, and git has Linus as a promoter which was all it needed to be the leader. That said, I agree that the network effect of having just one is more valuable than mercurial's ergonomics (which could still use a good branch story).

Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage). There’s a meme that Git is hard to use but I think it’s conflating…

> I watched a number of developers do that and it was about as much work to go from SVN to either Git or Mercurial, and if they learned the other DVCS it was always easier since they were mapping concepts rather than learning them for the first time.

We recently adopted a tool that uses Perforce as a backend. It's been interesting to try and describe centralized version control to younger engineers who have only used a dcvs like git.

Re: I kind of killed Mercurial at Mozilla

#216

Post by steveklabnik »

shepherdjerred wrote: post #65
steveklabnik wrote: post #25

Earlier quoted context omitted.

I know people who express similar feelings. Usually it is shorthand for "I would prefer stacked diffs" or similar. Two blog posts I've seen people point at: * https://mitchellh.com/writing/github-changesets * https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/

I've found that Graphite [0] has solved this issue for me. It's makes the experience of shipping stacked diffs about the same as the CR tool within AWS [0]: https://graphite.dev/

Thanks for this. I admittedly still don't really grok it, but maybe if I play around with the tooling, something will click.

Re: I kind of killed Mercurial at Mozilla

#217

Post by WorldMaker »

G3rn0ti wrote: post #165
alex_smart wrote: post #133

Earlier quoted context omitted.

Essentially, the problem with git is - it is a tool that is simple in its internals, but with a complex/confusing UI. The only way for someone to feel somewhat in comfortable with git is to have a good conceptual model for how it works internally. Once you have that mental model, you feel like a magician with git, but for beginners, it is a source of endless confusion and fear.

GIT is a tool. Like a swiss army knife, it looks tricky and you need some experience to master all what it provides. But you never actually need everything and, surely, you should also shy away from features if you do not really need them. In this respect GIT is a bit like Perl or C++. You have to apply some discipline to avoid unnecessary complexity. Personally, I have never used GIT's "octopus" merge support but I…

I like the in-progress `git checkout` split to `git switch` and `git restore`. (switch and restore are still marked "experimental" in the official documentation in case their arguments change again, but in my experience they are already pretty dependable.) It's much less likely to accidentally do the wrong thing with either of the two replacements. That's one of the things that I think if that split had been done years ago there would be a lot fewer complaints about git being confusing in the base commands; `git checkout` was always an odd duck sadly (it makes sense why it was a single command from a technical sense but it probably shouldn't have ever been from a UX/DX sense).

Re: I kind of killed Mercurial at Mozilla

#218

Post by WorldMaker »

cmrdporcupine wrote: post #110
wsc981 wrote: post #108

I don't understand why so many people seem to dislike git. But maybe in actuality it is not many people, as usually people who are discontent are the loudest. I used Mercurial in the past for a bit, and it was fine. But for me it doesn't seem to have any huge advantages over git, if any. And after so many years of experience using git, I know what workflows work well, how to resolve merge conflicts, how to revert to…

Git functionality is great. But the CLI just kind of grew in a nonsensical way. No serious effort seems to have been made on UX consistency and verb/noun names. People who've been using it for years don't notice, they don't even think about it. But when coming from scratch, it's anything but intuitive. The CLI is not discoverable in a reasonable way. That and there's so many ways to use it. Mercurial had the advantag…

> Mercurial was never trying to "replace" git. All of these guys came out at the same time.

Mercurial even had a couple weeks' head start on git, and git partly happened trying to replace Mercurial in early experimentation. The name "git" was always an interesting self-deprecating choice because it was (intentionally) "stupider" than its competition that it knew about, which included Mercurial (and also darcs/Monotone/Bazaar).

Re: I kind of killed Mercurial at Mozilla

#219

Post by chx »

acdha wrote: post #200
chx wrote: post #186

Earlier quoted context omitted.

That's not a meme, many git commands have switches which make them behave wildly differently creating massive confusion.

Sure, but most of those are things you rarely need and it’s not like Mercurial was an AI which always knew what you meant - anyone who ever tried to explain merge-queues to someone else knows that some concepts are just harder than others.

No need for hard concepts.

I am talking of things like "opsie, I don't want to commit this yet" (git reset) and "destroy all my work" (git reset --hard) being a command line switch apart. That's just wrong. That's so wrong I keep git reset --hard safety net around, in fact. https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29

Re: I kind of killed Mercurial at Mozilla

#220

Post by WorldMaker »

oktwtf wrote: post #42

My only experience with Mercurial was in game development. What’s used these days in arenas where large file versioning is needed? I think the ultimate answer is maintaining an asset stack containing files that allow for inherit diff chunks or however that might be described.

Git LFS is supported by most hosts these days. It's "fine".
Post reply on HN