Good news: I managed to create a branch based on a generic SHA1 directly from the GitHub GUI. This allows us to set labels to the pre-push SHA1 for fetching and recovering them.
@Kohsuke: do you want me to create those labels on the mentioned projects ? humbug-plugin => *OLD* (pointing the post-push SHA1) scoring-load-balancer-plugin => *OLD* (pointing the post-push SHA1) Luca. On Tuesday, November 12, 2013 11:43:00 PM UTC, lucamilanesio wrote: > > Hi Kohsuke, > I agree with your conclusions ... that was my impression as well when I > was analysing the 54 repos with pre = post: possibly Nathan thought that no > other pushes were made after my forced push on Sunday. > > One more detail about the 4 discrepancies on the pre-push SHA1: > comparing the pre-push SHA1 / post-push SHA1 and their respective commit > dates, I would say that *your* pre-push SHA1 seems correct: possibly then a > manualy "copy&paste" mistake by Nathan. > > With regards to the current situation of those 4 repos: > git-client-plugin => OK > humbug-plugin => *OLD* (pointing the post-push SHA1) > promoted-builds-plugin => OK > scoring-load-balancer-plugin => *OLD* (pointing the post-push SHA1) > > Last point: how to recover old SHA1 that were not labelled by Nathan ? > You can actually create a branch from the GitHub GUI: I will check if you > can specify the branch point with a SHA1 so we can do it ourselves as well. > > P.S. Let's not forget the repos with the other non-master branches to > recover :-) > > Luca. > > > On Tuesday, November 12, 2013 11:27:07 PM UTC, Kohsuke Kawaguchi wrote: >> >> On 11/12/2013 02:34 PM, Luca Milanesio wrote: >> > I will cross-check with the list provided by GitHub. >> > (was doing a similar exercise on the suspect 54 repos anyway) >> >> Yes, please cross check to validate my sanity. >> >> I've compared this list with the CSV file from GitHub that you posted >> earlier. The program I used is in the same GitHub repository. >> >> https://gist.github.com/kohsuke/7440208 >> >> This is not the best formatted text, but the way you read this is that >> given a line like this: >> >> > >> GitHub:220610b->64db20c Kohsuke:220610b->c5bcbfd >> build-pipeline-plugin >> >> >> According to GitHub's CSV, Luca has overwritten 220610b by 64db20c, but >> according to my program that looks at the event API, Luca has >> overwritten 220610b by c5bcbfd. This is the master branch in the >> 'build-pipeline-plugin'. >> >> So one naturally wonders where the discrepancy comes from, and when I >> look at the events output, I think it becomes clearer: >> >> - open [1] in the browser (I captured this as of this writing in [2]) >> - This records Luca's push in line 350 (event ID: 1883629947) >> - Head was 220610b and the push moved it to c5bcbfd, which is the >> value my program reported. >> - And if you scroll up, you see jenkinsadmin had pushed after luca >> did, moving the ref from c5bcbfd to 64db20c, which is the value >> GitHub CSV reported. This is probably Nicolas pushing changes from >> jenkins.ci.cloudbees.com workspaces, which explains the login name >> "jenkinsadmin" >> >> My guess is that Nathan took the "force pushed to" SHA1 by looking at >> the commit the master branch was pointing to, when he did his thing. >> That is to say, if somebody has pushed changes after Luca did but before >> Nathan looked at, that'd create a discrepancy in our two data. >> >> In any case, the tip of the branch after a forced push is less >> interesting. What's important is what the tip was before Luca's push. >> >> So my program pays special attention when two data reports different >> commit IDs as to what the repository was pointing to before Luca's push. >> [2] prints out "^^^ discrepancy on the original commit ^^^ " when that >> is the case. >> >> Fortunately, there's only four of them. This includes >> scoring-load-balancer-plugin reported by ikedam, which gives me a bit of >> confidence in the approach. I'm going to look at these four more >> carefully. >> >> >> This exercise also revealed another data loss not caught earlier by >> GitHub's CSV, which are pushes to branches other than the 'master' >> branch. The data from the events API correctly report them, and you can >> see them all in [2] as well. >> >> >> Since Git does not allow retrieval of commits by their SHA1, I'm going >> to try if Git would let me tag a commit that I don't have locally. At >> some low enough level this should work, but I don't know if the command >> line git would take it. If that doesn't work, I think we need to >> assemble the list of SHA1 and ref names so that we can ask someone from >> GitHub to create refs for them. >> >> >> In the mean time, if you notice any data loss that's not in the >> 'recovery' branch, please let us know so that we can continue to >> validate and verify our salvage efforts. >> >> >> [1] https://api.github.com/repos/jenkinsci/build-pipeline-plugin/events >> [2] https://gist.github.com/kohsuke/7440304 >> >> > Luca. >> > >> > On 12 Nov 2013, at 21:27, Kohsuke Kawaguchi <k...@kohsuke.org> wrote: >> > >> >> >> >> As I suggested in the e-mail thread, I've written a little program >> that looks at the GitHub events API to figure out the push activities from >> Luca, and assembled a list of refs and affected commits. The result is in >> [1]. >> >> >> >> The exact code is at [2], and I invite others to check my sanity. The >> basic idea is to look at the events time line, and find the problematic >> push. >> >> >> >> The meaning of the output is: >> >> >> >> repository name, before, after, ref >> >> >> >> "before" is the commit that's lost. >> >> >> >> I'm going to compare this with the CSV file from GitHub now to see if >> there's a pattern of discrepancy here. >> >> >> >> [1] https://gist.github.com/kohsuke/7438914 >> >> [2] >> https://github.com/jenkinsci/backend-git-pushf-finder/tree/eeb462c47dbaa45f2170ccada487eed33da81193 >> >> >> -- >> >> Kohsuke Kawaguchi http://kohsuke.org/ >> >> >> >> -- >> >> You received this message because you are subscribed to the Google >> Groups "Jenkins Developers" group. >> >> To unsubscribe from this group and stop receiving emails from it, send >> an email to jenkinsci-de...@googlegroups.com. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > >> >> >> -- >> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ >> Try Jenkins Enterprise, our professional version of Jenkins >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
