3 ms·

Git doesn't nuke objects until you explicitly ask it to. It might sync broken objects, but it won't actually chose to destroy dangling objects without being as

by richo 14y ago

Git doesn't nuke objects until you explicitly ask it to. It might sync broken objects, but it won't actually chose to destroy dangling objects without being asked to.

DougBTX 14y ago
They say in the article that one step of the anongit sync is to delete projects from the anongit servers which have been deleted on the central server. If a user accidentally deletes a project, they should be able to recover it from a backup, but it doesn't sound like there are any backups. The same idea applies to the individual repos themselves. A git gc will delete objects unreferenced by the reflogs, eg deleted branches over a month old by default. They say that the total set of repos is about 25GB, so it would be reasonable to keep at least monthly backups for at a year or more.
- sho_hn 14y ago
  We do ref backups on branch deletions FWIW.
  - DougBTX 14y ago
    Yea, that sounds like a good idea, can you do that in something like a pre-push hook? That plus long reflogs seems like it would make recovery of rebased/deleted branches really easy for end users.
    - sho_hn 14y ago
      We don't allow force-pushes without admin involvement, so rebasing isn't so scary for us, but we do cover it that way. And we got the undo operation down to a command on the infra: http://community.kde.org/Sysadmin/GitKdeOrgManual#ohnoes http://community.kde.org/Sysadmin/GitKdeOrgManual#ohnoes The rest of that Wiki page is also pretty interesting for a general look at what devs can do on git.kde.org - server-side personal clones, personal repositories, a personal trashcan for repositories, etc. We don't have a pretty web interface for it (yet?), but it has some nice features.
pja 14y ago
(This is missing the wider point, but regardless: AFAIK (do correct me if I'm wrong) git clone --mirror will not copy dangling references & those refs will disappear from the original after a git gc, whenever that happens.) Human error is human error: sometimes people will do apparently egregiously stupid things if it's possible for them to do so, including things like deleting branches from a repository & then doing a git gc to "save space" shortly before realising that they weren't issuing commands to the shell they thought they were in. A backup strategy should be robust against dumb human mistakes as well as mechanical hardware errors, otherwise it's no backup strategy at all.

by richo 14y ago

Git doesn't nuke objects until you explicitly ask it to. It might sync broken objects, but it won't actually chose to destroy dangling objects without being asked to.

DougBTX 14y ago

They say in the article that one step of the anongit sync is to delete projects from the anongit servers which have been deleted on the central server. If a user accidentally deletes a project, they should be able to recover it from a backup, but it doesn't sound like there are any backups. The same idea applies to the individual repos themselves. A git gc will delete objects unreferenced by the reflogs, eg deleted branches over a month old by default. They say that the total set of repos is about 25GB, so it would be reasonable to keep at least monthly backups for at a year or more.

sho_hn 14y ago
We do ref backups on branch deletions FWIW.
- DougBTX 14y ago
  Yea, that sounds like a good idea, can you do that in something like a pre-push hook? That plus long reflogs seems like it would make recovery of rebased/deleted branches really easy for end users.
  - sho_hn 14y ago
    We don't allow force-pushes without admin involvement, so rebasing isn't so scary for us, but we do cover it that way. And we got the undo operation down to a command on the infra: http://community.kde.org/Sysadmin/GitKdeOrgManual#ohnoes http://community.kde.org/Sysadmin/GitKdeOrgManual#ohnoes The rest of that Wiki page is also pretty interesting for a general look at what devs can do on git.kde.org - server-side personal clones, personal repositories, a personal trashcan for repositories, etc. We don't have a pretty web interface for it (yet?), but it has some nice features.

pja 14y ago

(This is missing the wider point, but regardless: AFAIK (do correct me if I'm wrong) git clone --mirror will not copy dangling references & those refs will disappear from the original after a git gc, whenever that happens.) Human error is human error: sometimes people will do apparently egregiously stupid things if it's possible for them to do so, including things like deleting branches from a repository & then doing a git gc to "save space" shortly before realising that they weren't issuing commands to the shell they thought they were in. A backup strategy should be robust against dumb human mistakes as well as mechanical hardware errors, otherwise it's no backup strategy at all.