Yep. One thing I like to ask is, does your project have millions of lines of code, being worked on by thousands of developers scattered around the globe? If not, you might want to think about whether Git is really the best fit for your needs.
Apart from its ubiquitousness, these are all neutral features: there are lots of crappy piano players out there who might be better off learning a different instrument, but if you don’t have any other preference it’s hard to go wrong with the default choice. Git is one of those tools where it’s really not worth the trouble looking elsewhere unless you know what you’re looking for, because there’s value sometimes in going with the flow. Whether it was for the best that git was the tool we all settled on, I think there’s some good in the fact that we settled on something.
It legit may be a few % better for a few workflows, but why die on that hill?
Is that the same Mercurial that didn't even supported stashing local changes?
Exactly what does anyone stand to gain by switching from Git ti Mercurial?
Git stash however, is one place where it's just crap. `git stash apply stash@{3}` ?!?!? No. omg no. Sure, for "hey it works" but not for "hey let's have this be the standard interface that we give to everyone and never improve" After all these years we still can't say `git stash apply 3` ??? really?
also git stash is wildly divergent in terms of conventions relative to all the other commands.
But it’s a good example of why mercurial was better. It’s more ergonomic. All of the parameters on shelve match what you’d see on other hg commands and to shelve and unshelve you use those commands, not pop and push. You can also give short names to shelves for use in the ui, not just the message or sha.
Not really. Mercuria's shelve extension existed for a while but it only saw its way into Mercurial Core and made available by default with the release of Mercurial 5.1.
https://www.mercurial-scm.org/wiki/ShelveExtension
I feel it's disingenuous to clam that a feature was provided by an application if it's only provided as an add-on that requires the user to explicitly enable.
The standard way mercurial added new features was to gate them behind configs and only after they were widely tested turning them on by default. This is a good thing!
Prior to shelve being included with the mercurial distribution a third party extension was available going back to 1.x (or perhaps before I started using it around 1.8). And get this, it also prioritized ergonomics and was largely just adapted directly.
Would you consider it disingenuous to claim that there's visual UIs for git? It seems weird to ignore extensions that are extremely well known within the community. Plenty of people recommend using Firefox because it supports better ad-blocking extensions, even though those are also "sold separately".
The right question is why did git need github in the first place (while svn didn't)
I also agree "distributed VCS" like git may be more complexity than many teams need. I can't remember the last time I worked on a repo offline (arguably the signature feature of distributed VCS), ever, although I can understand how this can be hugely helpful for some teams.
Sometimes decent software accidentally becomes a ridiculously broad standard. You can't resist that force by dismissing it as what it was originally meant for.
It doesn't matter if git is the best fit. ~Nobody under the age of thirty is picking between git anything else any more than they're picking between Linux and anything else to run their single node/java/postgres process on their prod servers.
This personal assertion makes no sense. What leads you to assume that just because an application scales beautifully that automatically means it doesn't fit your needs?
I mean, you don't even bother trying to argue feature X is disappointing or feature Y is missing. Your whole point is that git scales so if you don't need scale then... Then what?
The truth of the matter is that Git works fantastically well both with personal static website projects with a dozen files and with million loc behemoths, whether in local repo only or with multiple remote repositories.