4 ms·

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 ba

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. https://stackoverflow.com/questions/3640764/can-i-recover-a-branch-after-its-deletion-in-git https://stackoverflow.com/questions/3640764/can-i-recover-a-...

stouset 4y ago
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.
- CJefferson 4y ago
  Yes, as you say, I'd have to write the commit names down, and eventually they would get garbage collected. You could tag, but then you are just polluting your tag namespace with old branches.
  - sicp-enjoyer 4y ago
    You can also search logs to recover a commit, besides the other ways mentioned. > ok but then I lose it's nice handle. Then don't delete the handle? Maybe rename it with a `deleted/` prefix? It's hard to imagine what the expected behaviour is when branch names are just local convenience labels.
- ecnahc515 4y ago
  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.
  - stouset 4y ago
    > 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.

stouset 4y ago

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.

CJefferson 4y ago
Yes, as you say, I'd have to write the commit names down, and eventually they would get garbage collected. You could tag, but then you are just polluting your tag namespace with old branches.
- sicp-enjoyer 4y ago
  You can also search logs to recover a commit, besides the other ways mentioned. > ok but then I lose it's nice handle. Then don't delete the handle? Maybe rename it with a `deleted/` prefix? It's hard to imagine what the expected behaviour is when branch names are just local convenience labels.
ecnahc515 4y ago
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.
- stouset 4y ago
  > 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.