There is only one thing about subversion I miss when using git -- the deletion of branches (which were, admittedly, just directories in a folder called branches) was version controlled, so you could recover deleted branches.
Just in case - you can in git as well. Branches are just pointers to a commit SHA, so can always create another pointer to the same commit and your branch is back.
I suspect GP knows this, but there's no way to go back and see what the branch ref was at a prior point in time. I believe they wish that refs themselves were versioned.
And yes, I know they're kept in the reflog. But that is short-lived and (I believe) local rather than eternal and global like everything else in git.
The reflog does exist on the server too, but it's not really accessible without access to the git repo on the server, so not much use in eg, GitHub. That being said, GitHub also exposes some of these details, for example: in PRs when you force push on your branch.
So in the general sense, there's no reason we can't have exactly what's being discussed, but it just doesn't exist yet.
> The reflog does exist on the server too, but it's not really accessible without access to the git repo on the server
Though it only logs refs that the server itself has seen, which is more or less what I meant by "local". None of its state is shared during push/pull, it's computed entirely based upon what some individual client/server directly observes.
I miss the name, SVN was pronounced Svend (SVeN) among my friends, which is a scandinavian male name.
"Have you committed your changes to Svend yet?", "No, Svend is experiencing some downtime right now", that was some fun interactions that got us through computer science.
Git is a fun name too, but it is not nearly as funny to me.
TortoiseSVN was a great SVN client integrated into Windows File Explorer, and it looked great when you used the classic theme on Windows XP.
Conversely, the deletion of branches is version-controlled in git, because when someone force-pushes or deletes a branch on the remote it can still be restored from anyone's clone :)
I've seen this happen a few times with a dev running `git push -f` with the intent to update their dev branch, except that it would force-push all branches in their clone that were associated with the remote, like master. It probably doesn't happen these days though, because the default was changed at some point to only push the current branch.