[grumbel]

> doesn't destroy the reflog or runs the GC server-side.

Git doesn't give you access to the server side reflog either. So it's of not much use if you don't control the server.

As for losing data with Git, the easiest way to accomplish that is with data that hasn't been committed yet, a simple `git checkout` or `git reset --hard` can wipe out all your changes and even reflog won't keep record of that.

[xorcist]

That data not committed to git can not be recovered by git should hopefully not surprise anyone.

Neither is it the fault of your version control system, or any other system really, if you cannot access your server and are without backups.

[bvrmn]

> As for losing data with Git, the easiest way to accomplish that is with data that hasn't been committed yet

Also Git has pretty awful behavior losing changes when one doesn't press "Save" in their IDE. Bad, bad Git.

[Spivak]

Your applications also shouldn't lose work when you don't press save, this is the entire impetus for the "recover unsaved work" in most document editors. A version of Git that shunted uncommitted changes to a special named stash whenever you did anything destructive would be a positive thing.

It's what I end up doing manually anyway but why make a system where the default behavior is destructive and I have to remember every.

[xorcist]

It may be prudent to note that git by default is rather kind in that way that it will not change your data unless you explicitly force it to with --force or --hard. I think git, as hard to learn as it can be, sometimes have a bit of an unfair reputation here. It's not all bad.

Not only is it quite careful about not losing data, someone actually took the time to make it spit out messages that not only describes what just happened, but also gives suggestions of what to do next depending on how the user wants to proceed. That adds a level of discoverability that is usually associated with dialog based guis. The quality of these messages can sometimes be surprisingly good, far from the Clippy-level helpfulness you sometimes see.

There are a few exceptions to the principle of not losing local changes, where you explicitly restore an old version of a file for example. But saying the default behaviour is destructive really gives a false impression.

But yes, you are absolutely right that a system to recover unsaved work is a good thing, but I would argue that it belongs at the editor level, not in a version control system. A user could have a number of files open that have local changes. The editor has a much better idea in which order changes were made, and which changes hasn't even been committed to disk yet.

[whartung]

I can't say I'm widely traveled, I have no idea how desktop Office works, but Apple does this so well.

Using their desktop apps, Pages, Keynote, Numbers, TextEdit, Preview, I never hit "Save". I just close the apps. When I come back, the windows reopen right where I left off.

I wish emacs did this. I honestly don't know what it would be like for a code editor to be "constantly saving". I guess I would adapt, but there are times when I do all sorts of changes and go "Ah, this isn't right" and just kill the buffer. The ultimate undo.

But there's a great feeling, to me, when I go to close the app (or shutdown the computer) and it just closes. No prompts, no warnings, just saves its state, shuts down, and comes back later. And with the ever popular "naming things" issue of computers, I have a bunch of just "Untitled" windows. They're there when I open the app, and that's all I need to know.

The nag factor and cognitive load reduction of that is just unmatched. "Just deal with it, I'll come back later, maybe, and clean it up". One less thing.

[Brian_K_White]

A month of work for a whole team was never even committed or stashed let alone pushed? That is not a git problem.