4 ms·

> So if you want both "commit very often" I honestly think that commit very often is overrated. It really ought to be save and back up your files very often.

by u801e 7y ago

> So if you want both "commit very often" I honestly think that commit very often is overrated. It really ought to be save and back up your files very often. When I implement something, I don't bother making commits until I have completed the features. I then take the diff against the code and then selectively stage parts of the diff and make commits out of them. If someone else wants to see what was done so far, I just send them the diff as it is.

icholy 7y ago
> It really ought to be save and back up your files very often. Git is the backup.
- 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.

by u801e 7y ago

icholy 7y ago

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

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.