3 ms·

I think it would be neat if GitHub detected and archived branches that are deleted or overwritten with force --push. I don't know how feasible this is but it wo

I think it would be neat if GitHub detected and archived branches that are deleted or overwritten with force --push. I don't know how feasible this is but it would make it more true that when code is pushed to GitHub, it's safe. Edit: what I have in mind is something like a Recycle Bin or Trash for deleted branches where you can restore a branch (with a different name, if needed) or delete it permanently. Not some esoteric git feature. I'd like if it were added to git (as an optional feature enabled in .git/config), but I'd want it to work more like stash than a feature for searching for things that were left behind.

mvermaat 12y ago
In a way that's already true, since the commits are still there (and included when you clone). They're just not discoverable. It would be neat though if GitHub added some UI magic to recover dangling commits, possibly using the knowledge of which branches previously pointed to them and/or push -f operations.
- benatkin 12y ago
  Aren't these part of what gets cleaned up by git gc?
  - mvermaat 12y ago
    That is true, but only when they're older than 2 weeks (or whatever you define with --prune). I don't know what GitHub's configuration is here.
  - 4mnt 12y ago
    Yes they are. But only after they get dropped from the reflog, after 30 days by default.
- js2 12y ago
  You only get the commits reachable from the refs you clone. i.e. anything under refs/heads/* by default. Unless a commit is reachable from a ref you can fetch, it is not retrievable to you and won't be in your clone. So unless GitHub can locate it via reflog and create a ref, you won't be able to access it.
ethomson 12y ago
I think that (and correct me if I'm wrong) what you're really asking for is for the reflog to be exposed in some way. Certainly I've force pushed before when I didn't mean to. When I went asking where the reflog was they (politely) offered to dig into my repo and give me a copy of my reflog. But I would have preferred if this was something that I could see easily myself.

mvermaat 12y ago

In a way that's already true, since the commits are still there (and included when you clone). They're just not discoverable. It would be neat though if GitHub added some UI magic to recover dangling commits, possibly using the knowledge of which branches previously pointed to them and/or push -f operations.

benatkin 12y ago
Aren't these part of what gets cleaned up by git gc?
- mvermaat 12y ago
  That is true, but only when they're older than 2 weeks (or whatever you define with --prune). I don't know what GitHub's configuration is here.
- 4mnt 12y ago
  Yes they are. But only after they get dropped from the reflog, after 30 days by default.
js2 12y ago
You only get the commits reachable from the refs you clone. i.e. anything under refs/heads/* by default. Unless a commit is reachable from a ref you can fetch, it is not retrievable to you and won't be in your clone. So unless GitHub can locate it via reflog and create a ref, you won't be able to access it.

ethomson 12y ago

I think that (and correct me if I'm wrong) what you're really asking for is for the reflog to be exposed in some way. Certainly I've force pushed before when I didn't mean to. When I went asking where the reflog was they (politely) offered to dig into my repo and give me a copy of my reflog. But I would have preferred if this was something that I could see easily myself.