It looks like you mindlessly associate a CLI with a poor -- or suboptimal -- user experience. In fact even your choice of weasel words conveys the idea that you want to mindlessly push an irrational belief in spite of not being able to provide arguments to support it. The truth of the matter is that git -- or any other VCS -- operated through commands that change the current state of the repo. The command line interface excels when the user wants to run commands. Any GUI developed for command line tool will end up doing nothing more than replicate what the CLI already does, and will do so poorly.
Put another way, Git is a process that can be rendered pictorially. Words (i.e., CLI) are a less intuitive abstraction.
Pardon me for stating the obvious :)
https://www.atlassian.com/git/tutorials/resetting-checking-o...
Understanding that git reset --soft moves HEAD but doesn't change the staged snapshot or working directory, whilst --mixed updates the staged snapshot to match the commit but doesn't touch the working directory was very useful. And knowing that reset --hard updates both staging and the working directory to the commit was where I suddenly "got it".
No way. Only if you define “good” as “good at the kind of project that git is good at,” where it will hold vacuously.
I suffer daily through the cyst that is git LFS, and it’s a joke. It would be funny if it weren’t so tragic. I hear that it’s not doing any better in large scale mono repo land. Google doesn’t use it, afaik. Microsoft does (but multi repo, last I heard), Facebook doesn’t (custom Mercurial, some tasty quotes at [0]). Not a glowing “fundamentally better”, exactly.
[0] https://code.facebook.com/posts/218678814984400/scaling-merc...
2. Microsoft uses Git in single large-scale mono repo form, for - believe it or not - Windows. It clocks in at about 3.5 million files, and a full clone weighs in at 300GB:
https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-large...
They had to change git itself to be able to do that. So no, the article itself shows it was not ready for that big a repository.
That’s my point: without LFS it’s even worse to work with large files. If LFS is the best option you have, forget it. That’s an entire area of projects (anything with assets) you can’t use Git for.
https://github.com/Microsoft/GVFS
Pretty cool stuff. Doesn't seem to address the large-files case so much as the many-files case, though. I would love better git support for large files.