Comment by chiefalchemist
7 years ago
It might not feelblike that big of a deal, but certainly there has got to be on any given day far more important things you can use those brain cycles for, yes? Low friction or not it's still friction. Friction that can be removed. Yet so many refuse to do so. There's something wrong with this this-is-how-we've-always-do-it picture.
You make it sound like tradition or a cargo cult—it's not. Git is fundamentally better than most of the alternatives, but in my opinion it's misguided to try to slap a better interface over the warts. Rewriting the porcelain would be good, but I don't think it's personally worth investing in until someone makes an attempt that's good enough to get traction and significant mindshare. In the meantime I've already made the investment in learning git and it pretty much stays out of my way.
Not to sound snarky / adversarial but why is it that (nearly) every article I see on Git has some sort of diagram within it? Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.
> Yet "execution" is typically limited to CLI? That just feels suboptimal, if not just foolish.
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.
1 reply →
The issue is with understanding staging and the working directory. The lightbulb moment for me was reading this article from Atlassian:
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".
1 reply →
> Git is fundamentally better than most of the alternatives
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...
That's a fair criticism for sure, git makes tradeoffs that fall apart with large repos. You can, however, go a whole career without those things being a problem. Most code repositories are simply not that big.
1 reply →
1. Git LFS is not part of Git. It's an unofficial extension, despite the name. I've got my own qualms about Git, but that's like complaining about GitHub's forking model as a reason Git is bad.
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...
2 replies →
I believe MS has most of windows in a git mono-repo now, enabled by a custom git-supporting filesystem they've developed:
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.