Hi Arnaud, thanks for the understanding :-) I am used to warn other people from doing any "forced push" ... and Murphy's law wanted this time happening to me :-(
On 10 Nov 2013, at 19:30, Arnaud Héritier <[email protected]> wrote: > Thx guys for these details. We are all humans and subject of doing errors. > I hope we'll have some help from github but I'm not sure they may spend many > time to help us for an error not coming from their side. Technically yes, but for the "customer relationship" and because it is an easy recovery (git reflog + git branch), they could make some effort to help us out. JenkinsCI is possibly the largest customer they have worldwide ;-) > In any case it is recommended to NOT PULL current master branches from these > repositories, your local copy may be more up-to-date. If you have a recent > hash you can at least try to push them in github under a branch named > "master-fix" the time we find the best solution to repare all master > repositories. > If you commited on these repositories since yesterday verify that you didn't > started your work from the wrong old hash. > > Idea : in our CI server logs we should be able to find the lastest hash of > each repo in the related plugin build. After that we have to find how to > restore them. It's easy to do it when you have this commit locally but AFAIK > it's not if it is only in the remote (you don't get orphelin commits when you > clone a repo) Yes, that's what I thought as well ... but definitely the "git reflog" on GitHub server would be more reliable. The CI workspace (assuming that Git clones are not shallow copies) may have as well those commits as well, but again GitHub would be safer and better IMHO. Luca -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
