My solution for this is a script that commits all my changes then tags the resulting commit with a basic descriptive name. Something like this:

    git discard bad-idea-didnt-work

Which creates a tag discarded-bad-idea-didnt-work, then resets back to the previous commit.

I can still find and rescue the changes later by looking at my tags.

Others have suggested using the stash for this but I prefer to keep my stash stack free for shorter-term contexts, eg. if I'm halfway through something but need to go checkout another branch briefly.

Would you mind sharing that script? It sounds useful.

You've already gotten tips based on git. But if you use a JetBrains IDE, you also have the local history there. Or can use the shelve functionality, which is like git's stash but a bit smoother.

I don't know how JetBrains IDEs do 'local histories' but FWIW VSCode recently also implemented "local file history"[1]. I have not had to use it to salvage anything yet, but I'm sure that day will come.

[1] https://twitter.com/code/status/1511463379210317824

I was surprised to learn a few months ago from https://news.ycombinator.com/item?id=28958613 that the "git reset --hard" does not actually delete the files and you can still recover references to them using "git reflog".

I'm pretty sure most git users (who know what "git reset" is) don't realize this!

You need to commit them first. If you did not commit them, it doesn't work. But yeah, maybe I can just define an alias to add+commit+reset, which should solve this problem.

I just stopped worrying and commit everything into my own repos, even half baked or temporary, making sure that a commit message or a file name signals it clearly. It’s a versioning system for this exact purpose, not a ceremonial sanctuary.

Exactly. To me, some branches are quality, some are quantity.

You can also stash them which is effectively a commit into a special stash stack

You could just call `git stash` instead of `git reset --hard`. It'll have the same effect on your working directory, while also "backing up" the changes.

Stashes could be cleared using a cron job.

iirc stash works more in a stack like manner? Say if you do git stash, and then do git rebase -i to clean up the history, proceed to write some other features, git stash again to clean it up, etc. Can you recover the files for the first stash?

Yes, you can. If you save, apply or pop with git stash with no arguments, it works like a stack by default, but you can also access the other entries. For example `git stash pop stash@{n}`, where n is the index of the entry in the stash "stack", applies the nth stash entry on top of the working tree and then removes it from the stored stashes. The latest entry is at index zero, so stash@{0} would be the last saved/pushed one.

You can see a list of saved stashes and their indices with `git stash list`.

Ah you can use pop with other stashes too, thanks for the tip... though that feels a bit like a semantic misnomer (? unsure what term would be best to describe what I'm thinking - but 'pop' kind of feels like it should always be applicable only to the top element in a stack. I'd be scared that popping stash@{5} would apply all of stashes 1 to 5 at once lol).

I've been using `git stash apply stash@{n}`, which works just fine, but the stash is then not removed from your list and results in clutter.

> though that feels a bit like a semantic misnomer

It does, but then, this is the git command-line interface. :)

My understanding is that the stash pop command is simply an apply plus the removal of the successfully applied stash. The man page reflects this. It does not pop everything above element in the list.

git stash list?

In situations like this you could use `git stash` instead of completely deleting it.

Yeah git reflog will show you the previous commit (in a pretty confusing way tbh but it does the job). The original files will get GC'd by git at some point.