3 ms·
I worked in online IDEs which did automatic backups, and it was useless. Those timestamps don’t mean anything to me, and diff interface was very bad. But semi-
by theamk 7y ago
I worked in online IDEs which did automatic backups, and it was useless. Those timestamps don’t mean anything to me, and diff interface was very bad.
But semi-automatic backups, a.k.a. frequent git commits, are very helpful. For me, three-word commit messages like “no longer segfaults” or “will try sets” are exactly what I need, as they easily let me find out what exactly did I do so it segfaults again, or to revert code a bit if it turns out the sets are not a great idea.
Of course no one else, including me, would care about this once the feature is done, and that’s where rebase comes in.
- u801e 7y ago> For me, three-word commit messages like “no longer segfaults” or “will try sets” are exactly what I need, as they easily let me find out what exactly did I do so it segfaults again, or to revert code a bit if it turns out the sets are not a great idea. If you're going to end up squashing all those in progress commits down to a single commit, then that will work. If you're going to try to make several logical commits, then it becomes a bit more difficult (unless you just take the diff from the original branch and start over on a new branch). I actually find that using the multi-level undo feature in my editor sufficient for trying out small changes to see if they work or not. That is, if I get to a point where I can't figure out what I messed up, I can simply run something like :earlier 5m to go back to what the state was 5 minutes ago and get back to a working state.