Create a WIP branch, and keep working in there committing as often as you want, then squash the history if you don't want it all when you are ready to put the changes in the “real” branch that you are working on?
What I've done since before git was a thing is a variant of my backup process: my main work areas are synced using rsync⁰ to a copy¹ that is the head of a series of snapshots. If this ends up containing any newly created/modified files²³ a new snapshot is created using `cp -al`. This way I don't have to remember to commit regularly, and I have an automatic trace of everything I've done to a certain granularity⁴. The snapshots are given a name based on the contents of a text file, if present, so I can label points in time (otherwise the snapshot names are just timestamps). Tidying up is easy, just delete old snapshots with `rm -rf`, you could automate this if you like⁵ but I've never felt the need to. The not having to remember to do anything is key for me - over the years it has saved me⁶ from harmful edits not noticed for some time that might otherwise have been more of a pain to recover from. You could do similar per repo with the WIP-branch-in-git option: have script that scans for projects in that named branch, for any found check `git status`, if there are any changes commit with the timestamp as the commit message.
--------
[0] set to ignore a few things like .git directories and some artefacts that I would list in .gitignore
[1] off on a server, that isn't key but it does give me protection against the work machine going boom as well as from accidents off my own doing
[2] detected by looking for files with only one link to them, this can be an expensive check over huge numbers of files but not for what I'm using it on
[3] the sync deletes files too, though I don't use such changes on their own as a reason to create a new snapshot
[4] much higher than the 24-hour granularity that my normal backups have, about 1440 times smaller in fact
[5] keeping them for a maximum amount of time, perhaps, and/or more complex heuristics like not keeping too many copies that are only a few minutes or less apart
[6] only a few times, but more than enough to make me glad I implemented it!
Razengan · · focus · HN ↗
dspillett · · focus · HN ↗
What I've done since before git was a thing is a variant of my backup process: my main work areas are synced using rsync⁰ to a copy¹ that is the head of a series of snapshots. If this ends up containing any newly created/modified files²³ a new snapshot is created using `cp -al`. This way I don't have to remember to commit regularly, and I have an automatic trace of everything I've done to a certain granularity⁴. The snapshots are given a name based on the contents of a text file, if present, so I can label points in time (otherwise the snapshot names are just timestamps). Tidying up is easy, just delete old snapshots with `rm -rf`, you could automate this if you like⁵ but I've never felt the need to. The not having to remember to do anything is key for me - over the years it has saved me⁶ from harmful edits not noticed for some time that might otherwise have been more of a pain to recover from. You could do similar per repo with the WIP-branch-in-git option: have script that scans for projects in that named branch, for any found check `git status`, if there are any changes commit with the timestamp as the commit message.
--------
[0] set to ignore a few things like .git directories and some artefacts that I would list in .gitignore
[1] off on a server, that isn't key but it does give me protection against the work machine going boom as well as from accidents off my own doing
[2] detected by looking for files with only one link to them, this can be an expensive check over huge numbers of files but not for what I'm using it on
[3] the sync deletes files too, though I don't use such changes on their own as a reason to create a new snapshot
[4] much higher than the 24-hour granularity that my normal backups have, about 1440 times smaller in fact
[5] keeping them for a maximum amount of time, perhaps, and/or more complex heuristics like not keeping too many copies that are only a few minutes or less apart
[6] only a few times, but more than enough to make me glad I implemented it!