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

I'm going to slowly move on from Mercurial

mercurial-scm.org

Post reply on HN
Print view View original

131–140 of 165 posts

Re: I'm going to slowly move on from Mercurial

#131

Post by scrollaway »

krupan wrote: post #85
JoshTriplett wrote: post #77

Earlier quoted context omitted.

> "I find [the index] a critical part of git's culture of making small commits with one logical change each." > I've never understood why the index has to be forced on everyone for every commit. You can generally bypass it if making a simple commit; I use "git commit -a" all the time. But every time you use tools like "git add" on individual files, or "git add -p" on parts of files, you rely on the index. Understandi…

"Understanding the index also helps greatly when you need to do a merge, cherry-pick, or other similar operation; you need a staging area to work in, separate from the work tree." Actually, with mercurial I don't need a staging area to work in separate from the working copy to perform merge, cherry-pick, or other similar operations. The index appears to be needless complication.

Having used both git and mercurial extensively I can guarantee you the index is not a needless complication, it is a feature sorely missed in hg.

Re: I'm going to slowly move on from Mercurial

#132

Post by warbiscuit »

BuckRogers wrote: post #7

Matt has done a great job and I wish hg had taken off more than it did, though it would be disingenuous to suggest it hasn't been successful. I used hg before moving to git and always preferred the clean, single language implementation vs the scripts and general hackish nature that git offered as an alternative. As a result, it was a nice perk for a long time that hg worked much better than git on Windows.

I'm worried I might have to move off of hg eventually. But just can't get over all those points .. and also TortoiseHg, for which there doesn't seem to be even remotely as good an equivalent in the git ecosystem. It's kind of frustrating. I end up cloning git projects using hg-git plugin just so I can use it to search the repo history.

Re: I'm going to slowly move on from Mercurial

#133

Post by ufo »

JoshTriplett wrote: post #129
Karunamon wrote: post #120

Earlier quoted context omitted.

This comic is shockingly spot on for me and my group. We all know the basics, but only at a "type this to get this result" level. The moment something ridiculous needs to be done like a rebase, I get called, and without fail need to have a few stack overflow tabs open to figure it out. Git's a phenomenal system, but sometimes part of me thinks it does require a PhD to fully grok.

I think that comic also accurately describes the problem leading to that as well: it dismisses any explanation of Git's underlying mechanics and repository structure as ignorable rambling prefacing the command to do what you want. It took me a while to learn git, and the explanations I went through involved the underlying structure of the repository. They seemed excessively complicated at the time, compared to memori…

Learning git internals can be useful but I'm really sad that its also required. If git's UI weren't so leaky a beginner would be able to go very far with just the "graph theory model" as guidance, which is much simpler to understand.

Re: I'm going to slowly move on from Mercurial

#134

Post by ufo »

dochtman wrote: post #84

I was a Mercurial crew member for a few years (2008 to I don't know) and was very happy to be able to learn from Matt in his role as BDFL. His principled stance against layering violations and his policy to require really small commits still influence my coding every day. I hope he finds something new to give him satisfaction/joy!

What do you mean by "layering violations"?

Re: I'm going to slowly move on from Mercurial

#135

Post by prewett »

JoshTriplett wrote: post #129
Karunamon wrote: post #120

Earlier quoted context omitted.

This comic is shockingly spot on for me and my group. We all know the basics, but only at a "type this to get this result" level. The moment something ridiculous needs to be done like a rebase, I get called, and without fail need to have a few stack overflow tabs open to figure it out. Git's a phenomenal system, but sometimes part of me thinks it does require a PhD to fully grok.

I think that comic also accurately describes the problem leading to that as well: it dismisses any explanation of Git's underlying mechanics and repository structure as ignorable rambling prefacing the command to do what you want. It took me a while to learn git, and the explanations I went through involved the underlying structure of the repository. They seemed excessively complicated at the time, compared to memori…

One of my problems with git is that I don't want to have to understand anything and source code control. It isn't something I am interested in. All I want to do is merge from upstream and commit my changes. Mercurial lets me do this without needing to understand much, whereas git makes me understand all sorts of stuff just to get this basic job done. Why should I have to understand the structure of the repository to merge something? Seems like a classic case of the UI exposing the implementation details. I get that if you are managing a large project you might want all of Git's features, but since that's not me, I just do what the XKCD comic suggests.

Re: I'm going to slowly move on from Mercurial

#136

Post by carussell »

JoshTriplett wrote: post #128
carussell wrote: post #125

Earlier quoted context omitted.

It's not Mercurial and Git line ending conventions, it's that Windows uses CRLF and Unix uses LF, and Git's approach to addressing this is pretty far short of good. (Another pre-emptive response: yes I'm aware of both core.autocrlf and "text eol", but those are exactly the sort of sideways-cutting non-fixes that I'm talking about.)

What's the behavior you expect, compared to the behavior that you get with git's configuration options?

I've tried to write and rewrite this comment, but it oozes disdain every time. So here's my best:

I expect that if a file uses CRLF everywhere, `git merge` will not leave it in a state with mixed line endings after inserting conflict resolution markers that end in LF instead of CRLF.

This shouldn't require a configuration option, but if it does, fine. However, Git doesn't even seem to have this.

What it does have are 'autocrlf' and 'eol' and 'text' options/attributes. For anyone who mentions those, I'm going to ask that you be familiar with not just what those actually control, but also how they're documented in the git man pages and in the book from git-scm.org—the entire premise was a discussion about Git's user-facing parts. By either source, those options control line normalization (i.e., implicit automatic conversion), which is not what I'm talking about. And the documentation for those is sick enough that even if they were the things to look to in order to configure this, then the idea that Git's UI is on par with Mercurial nowadays would still be wrong.

EDIT: To clarify, the desired approach for this is, "Use whatever line endings the file is already using". Git's approach to this is, "Standardize on either LF or CRLF, and at your discretion enable what amounts to some glorified git hooks to ensure that policy is followed, through the use of some obtusely documented configuration options. Make sure to work around any problems with that (e.g., when it's corrupting files that should have never been normalized) by applying another liberal layer."

Re: I'm going to slowly move on from Mercurial

#137

Post by harry8 »

You find yourself in a realm where hackers don't branch and use svn with no experience of distributed source control.

hg is so much your friend here. They will actually probably get over the switch hump and use it. git that hump is much bigger and more arduous. Git is great, I like it. When you want to drag the team with you who aren't already sold, just go straight to hg every time. You're hacker, you can use either effectively and both are excellent tools.

Re: I'm going to slowly move on from Mercurial

#138

Post by exDM69 »

Karunamon wrote: post #120
bsder wrote: post #111

Earlier quoted context omitted.

> but on the availability of programmers who know how to use it The sheer prevalence of git "tutorials" would suggest that most programmers don't actually know how to use it. Relevant xkcd: https://xkcd.com/1597/

This comic is shockingly spot on for me and my group. We all know the basics, but only at a "type this to get this result" level. The moment something ridiculous needs to be done like a rebase, I get called, and without fail need to have a few stack overflow tabs open to figure it out. Git's a phenomenal system, but sometimes part of me thinks it does require a PhD to fully grok.

> The moment something ridiculous needs to be done like a rebase

Rebase, "ridiculous"? Uh oh. It's a very valuable tool and it's a quite simple concept. I agree that the user interface could be less confusing, though.

Git is just a malleable graph made out of patches. The concept is really simple (even simpler than hg). The UI could be better but the manpages are rather good at explaining how it works.

Re: I'm going to slowly move on from Mercurial

#139

Post by pjmlp »

slapresta wrote: post #100
krupan wrote: post #97

I'm really surprised by the "git won" mentality that manifests in any discussion of mercurial as of late. It makes no sense. We don't decare "winners" with other tools we use. Do we? Why are we all playing with new programming languages when C won? Or maybe C++ won? Or Java? Did emacs or vim win? Speaking of text, did ASCII win? Which code review tool won? How about continuous integration tools? or build tools? I mea…

Code collaboration tools have a strong network effect due to them being ultimately social tools, and we expect categories affected by the network effect to have winner/losers mechanics. Of course, they don't actually have to, but it's a common expectation and a common outcome. For equivalents to "code collaboration tools", instead of "programming languages", "text editors" and "build tools", try "social networks" (Fa…

> English won

English did not won.

It might be widely spoken in the 21st century, but so were Greek, Egyptian, Latin, French, Portuguese and Spanish once upon a time.

I might be writing this in English now, but saying it won implies no change in common language will ever happen again.

Given the history of mankind and some of the countries I had the pleasure to visit on my life so far, I doubt it.

Specially since most of the people I know, do happen to speak three foreign languages on average.

Re: I'm going to slowly move on from Mercurial

#140

Post by cyphar »

carussell wrote: post #136
JoshTriplett wrote: post #128

Earlier quoted context omitted.

What's the behavior you expect, compared to the behavior that you get with git's configuration options?

I've tried to write and rewrite this comment, but it oozes disdain every time. So here's my best: I expect that if a file uses CRLF everywhere, `git merge` will not leave it in a state with mixed line endings after inserting conflict resolution markers that end in LF instead of CRLF. This shouldn't require a configuration option, but if it does, fine. However, Git doesn't even seem to have this. What it does have are…

"Don't standardise on line endings" is not a good idea. The whole CRLF thing is already completely stupid. Why are you trying to justify a dumb design decision, and claim that trying to standardise the way source code line endings are stored is a bad thing.

Not to mention that you can't send CRLF in emails. So how are you going to email patches.

Post reply on HN