3 ms·
The momentum behind git is huge in a small community that thinks it is much more important than it really is. Hmmmm. Momentum is a moving target. I'd be blown
by famousactress 16y ago
The momentum behind git is huge in a small community that thinks it is much more important than it really is.
Hmmmm. Momentum is a moving target. I'd be blown away if there was another source control tool in history who's userbase has grown as quickly as gits has in the last few years. As for important, I don't really think any of my tools are 'important'. They just let me get important shit done.
Also, I don't even know what "Git's UI" is, but I'm sure you're right about it sucking. I do take for granted my level of comfort using CLI for source control.
I'd be curious about the details of your data loss bug. Most git data loss is user error (though I'll admit the ridiculously obtuse commands and concepts make these very easy to accomplish when learning the tool)
- Silhouette 16y ago> Also, I don't even know what "Git's UI" is, but I'm sure you're right about it sucking. FWIW, I meant the CLI. I have rarely seen an interface that manages to make a relatively simple idea seem so complicated. > I'd be curious about the details of your data loss bug. It must have been a couple of years ago, so I can't remember the exact details and I imagine it's been fixed by now anyway. Basically, there was a problem (duly documented in their bug tracker; it wasn't user error) where Git would refuse to update one copy of a repository from another properly. If memory serves, it was related to switching between branches in some way. It's possible that I was being unfair in calling it a data loss bug in Git, because I have a vague memory that they determined the remote repository itself wasn't corrupted if you knew how to rescue it. However, the effect was that the local working copy on my development machine didn't have the data in it that it should have, and ultimately I don't really care why my data isn't there, only that it isn't.