5 ms·

Githubs response: Good news from GitHub: they have extracted the full list of SHA-1 before the forced push ! Many thanks to Nathan Witmer :-) See below the fu

Githubs response: Good news from GitHub: they have extracted the full list of SHA-1 before the forced push ! Many thanks to Nathan Witmer :-) See below the full CSV with the SHA-1. He created as well a branch named 'recovery' that points to the candidate point for restoring the master branch. Hope this will help to sort out the remaining repos. Luca. > Hi Luca. > > Oh man, that sinking feeling! > > But, no worries: I've gone through each of the repos listed above and done the following : > > * retrieved the SHA for the previous `master` before you force-pushed > * created a branch called `recovery` pointing to each former master > > In some cases, these are the same. > > I can go further and reset the master refs to their former shas if you'd like, or you can recover these yourself. To do so, in each repo: > > $ git fetch > $ git checkout master > $ git reset --hard origin/recovery > $ git push --force origin master > > I've attached a csv containing the shas (former master and forced master) for each branch, for your reference. > > Good luck! > > Nathan.

LandoCalrissian 13y ago
That was incredibly nice of them.
lightyrs 13y ago
GitHub represents a new ideal in customer service. I hope other companies will begin to follow their example.
- gcb0 13y ago
  why couldn't they do those steps themselves? ...i'm not really familiar with github's git. I am having a really hard time understanding why a distributed VCS with hundreds of users needs the admin to the central repo to do anything for them.
  - cjh_ 13y ago
    The central repository is the only point that knows (with 100% certainty) which ref the branch was set to before the force push. Each distributed node only knows the ref the branch was pointing at the last time they fetched, so their certainty on what the branch looked like before the force push is much lower.
    - hrjet 13y ago
      In that case, such a service could/should be automated?
    - deathanatos 13y ago
      > The central repository is the only point that knows (with 100% certainty) which ref the branch was set to before the force push. git reports it to you when you do the force push: % git push github master --force … Total 0 (delta 0), reused 0 (delta 0) To https://github.com/foo/repo.git + 4d44b63...ad5b147 master -> master (forced update) ^ ^ previous what you've forced it to Of course, if you lose the output, then yes, the reflog is the only thing that has it. But force pushing is so rare, and something that (should) is done with care, I'm puzzled as to how someone "accidentally" >150 repos.
      - ricket 13y ago
        Luca details the three things that led to this mass force push in his message here: https://groups.google.com/d/msg/jenkinsci-dev/-myjRIPcVwU/v8PWC60lNEIJ https://groups.google.com/d/msg/jenkinsci-dev/-myjRIPcVwU/v8...
      - chatman 13y ago
        If losing this output is such a problem and force pushing is so rare, then Github could email this output with the two hashes to every developer on every force push.
        swift 13y ago
        This seems like a good idea. (With a setting to turn it off, of course.) Ideally git itself should record this information somewhere, though.
      - cjh_ 13y ago
        I was assuming after the fact as that information is not saved anywhere client side. Also I am not sure what he did to push to 150 remotes, and in that case this output would be much more tedious to piece together (and that is assuming he was able to capture all of it). However I disagree that force pushing is rare, I find it is a (sharp) tool I use most days (more often on private repos or branches). I do like the idea of github providing some kind of web interface to view the reflog and reset branches to various points within it.
  - deleted 13y ago
    [deleted]
  - Untit1ed 13y ago
    They didn't absolutely need to, but the alternative would be finding a user with the latest commit in their local git for every single repository, which could be 150 different people, then getting them all to push those changes... it's a bit more involved than just getting a github admin to put the repos back the way they were.
peter_l_downs 13y ago
You don't have contact info in your profile so I'm leaving a comment: awesome username!

LandoCalrissian 13y ago

That was incredibly nice of them.

lightyrs 13y ago

GitHub represents a new ideal in customer service. I hope other companies will begin to follow their example.

gcb0 13y ago
why couldn't they do those steps themselves? ...i'm not really familiar with github's git. I am having a really hard time understanding why a distributed VCS with hundreds of users needs the admin to the central repo to do anything for them.
- cjh_ 13y ago
  The central repository is the only point that knows (with 100% certainty) which ref the branch was set to before the force push. Each distributed node only knows the ref the branch was pointing at the last time they fetched, so their certainty on what the branch looked like before the force push is much lower.
  - hrjet 13y ago
    In that case, such a service could/should be automated?
  - deathanatos 13y ago
    > The central repository is the only point that knows (with 100% certainty) which ref the branch was set to before the force push. git reports it to you when you do the force push: % git push github master --force … Total 0 (delta 0), reused 0 (delta 0) To https://github.com/foo/repo.git + 4d44b63...ad5b147 master -> master (forced update) ^ ^ previous what you've forced it to Of course, if you lose the output, then yes, the reflog is the only thing that has it. But force pushing is so rare, and something that (should) is done with care, I'm puzzled as to how someone "accidentally" >150 repos.
    - ricket 13y ago
      Luca details the three things that led to this mass force push in his message here: https://groups.google.com/d/msg/jenkinsci-dev/-myjRIPcVwU/v8PWC60lNEIJ https://groups.google.com/d/msg/jenkinsci-dev/-myjRIPcVwU/v8...
    - chatman 13y ago
      If losing this output is such a problem and force pushing is so rare, then Github could email this output with the two hashes to every developer on every force push.
      - swift 13y ago
        This seems like a good idea. (With a setting to turn it off, of course.) Ideally git itself should record this information somewhere, though.
    - cjh_ 13y ago
      I was assuming after the fact as that information is not saved anywhere client side. Also I am not sure what he did to push to 150 remotes, and in that case this output would be much more tedious to piece together (and that is assuming he was able to capture all of it). However I disagree that force pushing is rare, I find it is a (sharp) tool I use most days (more often on private repos or branches). I do like the idea of github providing some kind of web interface to view the reflog and reset branches to various points within it.
- deleted 13y ago
  [deleted]
- Untit1ed 13y ago
  They didn't absolutely need to, but the alternative would be finding a user with the latest commit in their local git for every single repository, which could be 150 different people, then getting them all to push those changes... it's a bit more involved than just getting a github admin to put the repos back the way they were.

peter_l_downs 13y ago

You don't have contact info in your profile so I'm leaving a comment: awesome username!