I always fight for people really learning git, because that's when it finally starts to get good. And I always tell people that git is not the tool that everybody should use. Most people just need a simple data storage with diff management, like Dropbox or SVN.
But even after nearly 10 years, the pressure from the aint-nobody-got-time-for-that crowd is still there. I really, really hope that the git devs don't feel pushed to simplify and therefore depower git. Thinking turning VIM into the Windows text editor.
They can certainly provide much better porcelain out of the box. Mercurial is at least as powerful as git, but I always joked that the learning curve between the two is something like, you read the docs for 5 mins and you'll know what the next 50 commands to type into hg. Whereas git, you spend 50 minutes reading the Pro Git book, just so you know what the next 5 commands should be.
Sorry, but you don't know git if you think Mercurial is even coming close.
That is not trolling btw. It's really possible not to know what you can do with it if you haven't learned it in depth.
The "Git Book" is what you should read. And you read it once, you read it indepth, and then you're done. After that it's also only 5 minutes of googling, but you can do a lot more. At that point you can even program a simplified git if you want.
> Sorry, but you don't know git if you think Mercurial is even coming close.
And you don't know mercurial if you think that.
Both are great and powerful and both have pros/cons.
> The "Git Book" is what you should read. And you read it once, you read it indepth, and then you're done. After that it's also only 5 minutes of googling, but you can do a lot more.
The problem with git on this is it is actually often sort of hard to find "the right" way to do things. This
is in large part because of the popularity of git. There is so much content and a good deal disparate (e.g. Stack Overflow).
Mercurial on the other hand has far less content and it is maybe a little more consolidated and thus IMO slightly easier to find.
> At that point you can even program a simplified git if you want.
TBH, I've been an hg and git user for about 10 years now, I have only come across simple things that you'd expect to work in git but doesn't. For the longest time, you have to resort to contortions like this[1] so as to not lose commits after reverting a merge and then merge again.
I could name a few things, like interactive rebases, but the main thing is not something that can really be explained. Have you ever significantly become strong in some kind of contest, may it be sports, gaming, music or similar? There is this situation where one day you struggle with something and don't see an end, and the next day it finally clicks, and you can do things naturally that one day earlier where not even imaginable.
If you've experienced that once consciously, then you can regonize it and you know when you experience it you've hit someting really good in your life that moves you forward.
Sadly it seems you must take that hurdle in anything until a certain age or you will always believe this is impossible and therefore never invest the energy to reach it.
The thing is that this is not possible to achieve with any random software. For instance no matter how much you learn MS Word, you probably won't experience that. But when learning Vim or Emacs there's a chance you get there. Same is with git. And once you've achieved it once consciously, you will always want to be in that state in everything important you do.
That's why the really good stuff only has a few followers, most simply don't get the appeal because they never would invest the energy to get "there" even if they knew exactly how much it would take. But for those who have achieved it there is no going back. You cannot go back from controlling (almost) any bit of your repository to Mercurial.
But that's also why I think for most users something like Mercurial should be The VCS. Most people don't know the reward they are missing, so they don't feel the pain of missing it, and therefore have no logical reason to go through the pain of really learning git.
Long story short, you're using git because it makes you feel smart. Ironically, you even admit it - "therefore have no logical reason to go through the pain of really learning git". Correct, there is no logical reason to deal with a contorted DVCS when there are better alternatives. Your arguments are fully subjective.
If you tell a blind person, he should use the color red more when dressing, it might be a good advise, but for the blind person there is no logical reason to choose red over green.
What I'm saying is that most people are blind when it comes to skill, because they never make it over the hurdle once. But because most people don't have any skill, it is general consensus in our society to declare skills based on interest rather than the ability to solve hard problems or win competitions. I mean if one person is unable to judge if another person is good at solving merge conflicts, how could he criticize that person declaring himself as Git Expert Of The Team. And then again of course most people feel it is inappropriate to tell other people they are unskilled, so posts like this one get hated a lot on. But actually it's just calling out the facts. Sky is blue, grass is green, most people are too unskilled to even recognize what would enhance skills.
Unless I'm mistaken, people are paid to solve engineering/programming problems, not fight with a mess of a DVCS. And if I can use a Mercurial GUI and do in 15 seconds what would take 5+ minutes in the git command line, what's the point of being the Git Expert Of The Team? Is version control not used for saving work progress? A simple thing that 99.99+% of developers should be taking for granted in an ideal world, just like when pressing Ctrl+S in your IDE (hopefully) saves the file without asking what encoding you want to use and what partition you want it written on.
You seem to be under the impression that doing hard things has some intrinsic value, when it's not the case. You could be rolling rocks uphill all day and be the best in the world at it. So what? A keyboard going clicketyclack* for 5 minutes while typing git commands (and possibly stackoverflow queries) is the opposite of work, it's actually a waste of time. Sure, at the end of the day you solved the problem git presented you; you're smart, and feel satisfied with you amazing display of intelligence and skill. However, this ignores the fact that you should not have had to solve that problem to begin with, because your version control system should just magically work (unless you get a bonus for each git commit/merge).
> how could he criticize that person declaring himself as Git Expert Of The Team
I have no problem with someone being a git expert - I actually will even admit that I am not a git expert and that there are people extremely skilled at git. The issue here is that there are some people really skilled at, for example, typing using the backs of their fingers. Potentially impressive, but entirely useless. Saying you're skilled at git is like saying you're skilled at using Jira or editing Wikipedia; good for you, but in all but most extreme cases this doesn't actually generate value and it also doesn't make you a better developer.
> one person is unable to judge if another person is good at solving merge conflicts
Just out of curiosity, is this somehow relevant to git? Shouldn't solving a merge conflict be a simple matter of looking at a diff tool presenting you two inputs and one output screen? Or better yet, wouldn't it be better if you were automatically told you are editing a file someone else is working on, so that it prevents conflicts from happening?
I don't think git will lose features, and even if they do, git's core and data model is really, really good - if you look closely, most commands are relatively simple operations on the relatively simple data model and tree structure. I'd say they'll continue the current direction, mostly adding missing features and changing the defaults to be more sane (like default push mechanics).
Creating a sane and consistent UI for “git” is not the same as limiting its power.
They could have had every feature they do today without creating weird differences in options and terminology between sub-commands, and they could have set better defaults.
There needs to be an official “git 3” rethinking of options and defaults to solidify the foundation for the years to come and promote widespread adoption. Anything that simply tries to improve “git” as a layer on top will fail due to obscurity.
But even after nearly 10 years, the pressure from the aint-nobody-got-time-for-that crowd is still there. I really, really hope that the git devs don't feel pushed to simplify and therefore depower git. Thinking turning VIM into the Windows text editor.