Comment by erikb
7 years ago
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.
I am glad hg has both Facebook and Google using it. Otherwise Git would have suck the air out of DVCS.
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.
.... are you sure you are not trolling...
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.
[1]: https://github.com/git/git/blob/master/Documentation/howto/r...
What can't you do in Mercurial that you can in git these days?
BTW, I think we are talking about the same book.
5 replies →
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.