Not sure what you are looking for. What's wrong with stash? What ceremony are you referring to? `git stash` - `git stash pop` is as simple as it gets.
Then you can also do `git diff > changes.diff`. Or simply `rsync -avPh repo/ repo.snap/`, if your repo isn't huge. Or consider putting your repo in a filesystem that can do CoW snapshots.
I used to do this purely so that I could attach a name, then I found out that you can add a message when stashing: `git stash push -m "trying a thing"`
Stash is just a stack of commits. If you use stash this way too much probably you will mess something, since it needs to keep that stack data structure.
The solution: create a branch or tag with the things that you're trying. If you want to apply it, use `git merge --squash`. This way your unfinished work lives outside the stash stack!
git stash is given the UX of a stack, but it's more a list or a set of commits. The commits in your git stash don't need to be related (their commit parent pointers can point at very different branches). At some point if you are heavily using lots of stashes you tend to switch to referring to them by commit message and/or stash number instead of thinking it a stack you build bottom to top and always and only pop from the top.
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 ↗
gregoriol · · focus · HN ↗
m000 · · focus · HN ↗
Then you can also do `git diff > changes.diff`. Or simply `rsync -avPh repo/ repo.snap/`, if your repo isn't huge. Or consider putting your repo in a filesystem that can do CoW snapshots.
leni536 · · focus · HN ↗
moebrowne · · focus · HN ↗
lucasoshiro · · focus · HN ↗
The solution: create a branch or tag with the things that you're trying. If you want to apply it, use `git merge --squash`. This way your unfinished work lives outside the stash stack!
WorldMaker · · focus · HN ↗
everybodyknows · · 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!
Kinrany · · focus · HN ↗