Respectfully, Git still has a long way to go before it achieves parity with Mercurial, or even its state of the art from, say, 2010.
Don't discount the effect that familiarity with a tool or process can have on your perception of it. The most succinct explanation of this effect that I know comes from the title of a post on the Light Table blog called, "Pain We Forgot".
Coming from a Mozilla-influenced, pre-GitHub-explosion background, I'm one of those people always favored Mercurial but used both out of necessity. Mostly that meant using hg for my own stuff that is most likely never to see the light of day and git for almost everything else. But I also ended up calling it quits on Mercurial and pulled the trigger on git-for-everything last week.
So, having just written (what should be a completely unnecessary) tool to dump out stats about files' line ending conventions, again, I'll say that Git has a long way to go.
(And before you ask, yes the problem manifests itself using the latest version of Git, and there's nothing exotic or wacky to my workflow, nor am I witnessing the effect of interplay with other tools of dubious quality. This is an outright case of Git's tendency to drop the ball and then gesture in the vague direction of a poorly documented non-fix that cuts orthogonally to the problem it's supposed to be solving.)
Mercurial has some warts of it own. Common case of working on something, then wanting to update the repository in the midst of it to get something from a co-worker isn't handled exactly stellar.
So you can shelve. When you have enabled the extension.
If I'm not mistaken, even CVS handled this better.
This is way, way better than CVS. Some people complain about how this doesn't work in place, like git or shelve, but I prefer I don't have to change anything in my main repo, like regenerate IDE files, dependency caches etc.
Can you explain what's the relation between git or mercurial and files' line ending convention and what problem there is? I have used both and never met this kind of problem
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.)
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."
"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.
Don't discount the effect that familiarity with a tool or process can have on your perception of it. The most succinct explanation of this effect that I know comes from the title of a post on the Light Table blog called, "Pain We Forgot".
Coming from a Mozilla-influenced, pre-GitHub-explosion background, I'm one of those people always favored Mercurial but used both out of necessity. Mostly that meant using hg for my own stuff that is most likely never to see the light of day and git for almost everything else. But I also ended up calling it quits on Mercurial and pulled the trigger on git-for-everything last week.
So, having just written (what should be a completely unnecessary) tool to dump out stats about files' line ending conventions, again, I'll say that Git has a long way to go.
(And before you ask, yes the problem manifests itself using the latest version of Git, and there's nothing exotic or wacky to my workflow, nor am I witnessing the effect of interplay with other tools of dubious quality. This is an outright case of Git's tendency to drop the ball and then gesture in the vague direction of a poorly documented non-fix that cuts orthogonally to the problem it's supposed to be solving.)