3 ms·

> It really ought to be save and back up your files very often. Git is the backup.

by icholy 7y ago

u801e 7y ago
git is really meant to show a meaningful log of changes to the codebase. If one wanted to use it as a backup, there's no reason why one couldn't configure their editor to just run git commit -a -m "<current timestamp>" every time they saved, but that wouldn't result in a history that's useful in terms of being able to tell what actually changed and why.
- 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.

> It really ought to be save and back up your files very often. Git is the backup.

by icholy 7y ago

> It really ought to be save and back up your files very often. Git is the backup.

git is really meant to show a meaningful log of changes to the codebase. If one wanted to use it as a backup, there's no reason why one couldn't configure their editor to just run git commit -a -m "<current timestamp>" every time they saved, but that wouldn't result in a history that's useful in terms of being able to tell what actually changed and why.

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.