4 ms·
> because it's not great for non-power end users. Depends on what's the bar for "power users" I suppose. git is easy for the daily use case where nothing spec
by jjav 6y ago
> because it's not great for non-power end users.
Depends on what's the bar for "power users" I suppose.
git is easy for the daily use case where nothing special needs to be done and nothing goes wrong. But that's the vast majority of the time, so mostly it's fine.
It is when anything out of the ordinary flow needs to be done that it becomes impenetrable and often leads to data loss (or at least, an irrecoverable state which requires restoring from backup).
I've been using source control over 30 years now, with the vast majority of those years being on distributed source control systems (starting with Sun's teamware in the mid-90s). git is the one and only where I have had to adopt the practice of making a tarball of the current working dir before any nontrivial operation. And I end up having to use that backup every so often as git gets into some irrecoverable state of confusion.
Some of the comments in this and other git threads suggest (and I'll believe it) that if I were to dedicate substantial time to become an expert in the implementation detail and inner working of git, it might be possible to avoid these irrecoverable states. Ok.
That right there is an indication of a massive user interface failure.
- xolox 6y agoI'm not proud to admit (but I was interested to read that I'm not the only one) that I've gotten into the habit of making a tarball of my working directory and .git directory before large rebase operations between multiple feature branches, because like you I've lost work because git got into awkward states I couldn't get it out of without losing work. A full system backup of my laptops is taken roughly every three hours so it's quite hard for me to lose more work than that. However recovering from a failed rebase without losing changes can also consume a sizable amount of time, which explains why I'm still careful and take precautions anyway.
- fanf2 6y agoThere’s basically never an irrecoverable state in git, and it’s rare that you can’t recover “lost” data from the reflog. Yes it does require expertise to recover from a cockup, but you will never gain the expertise if you treat it as impossible. Note that you don’t have to avoid getting in a mess: it’s normal, when you are trying to do something unusual or advanced (or impossible in other version control systems) to make a mistake and accidentally blow your foot off, but git gives you the tools to glue your foot back on good as new.
- dwheeler 6y ago> There’s basically never an irrecoverable state in git That is technically correct but irrelevant. If a user doesn't know how to easily recover, then there's a problem. There should probably be a "git undo" command that always undoes whatever was done last. There's usually a way to undo a command (e.g., using the reflog), but the problem is that you have to know the correct incantation for every circumstance: https://github.blog/2015-06-08-how-to-undo-almost-anything-with-git/ https://github.blog/2015-06-08-how-to-undo-almost-anything-w...