4 ms·
"Unfortunately popular git GUIs all fail on giant repositories or become unresponsive and unusable." I have only witnessed that in magit (or pyright) when I ha
by pama 3y ago
"Unfortunately popular git GUIs all fail on giant repositories or become unresponsive and unusable." I have only witnessed that in magit (or pyright) when I have super deep directory trees (say a wide dataset collection) not yet in .gitignore and then git status takes forever in cmdline or in magit. But I don't think that there is a difference between a GUI or TUI or cmdline use of git in that case. Do other interfaces to git fail in more spectacular ways than git itself?
- eddieh 3y agoYeah, I never do a big merge in magit. I just use the git CLI for those.
- lolinder 3y agoIt's surprising to me if so. IntelliJ's git UI is more than fast enough, and it's written in Java and embedded in the IDE. An external git UI shouldn't have any issues.
- mschuster91 3y agoIntelliJ is only performant due to its indices of pretty much everything. That is its true magic. In contrast, the Git CLI and most if not all other UIs have zero sorts of caching and have to start from scratch for everything.
- lolinder 3y agoThat seems like a problem that could and should be solved.
- machomaster 3y agoIt's not a bug, but a feature. No cache is by design.
- mschuster91 3y agoThere's nothing stopping Git from storing its state in an sqlite db.
- lolive 3y agoIntelliJ has, imho, the most comprehensive & visual diff management UI. That thing alone discards any competitor [once again, imho].
- rtpg 3y agoMagit's failure mode is downstream of it (I believe) pulling in diff information on the status page. When I've had this problem, doing `git status` on the command line has always been more or less instant. There is something inevitable about needing time to display a lot of information. But I think magit is eager in some places that lead to extremely costly magit workflows when the raw git workflow would be much faster.
- deleted 3y ago[deleted]