Community
Participate
Working Groups
I'm very sorry, but I just pushed some commits to git://bdealwis@git.eclipse.org/gitroot/platform/eclipse.platform.ui.git) using bzr-git (which I've done previously with no issue), and somehow wiped out all the branches but two: master and R4_development (which I was pushing to). It would appear that I've somehow broken the repository too as Remy can't commit to the repository. Help!
(In reply to comment #0) > It would appear that I've somehow broken the repository too as Remy can't > commit to the repository. I've pushed some branches back, but they won't let me push some other ones because of the commit hook that prevents me from pushing stuff of another committer. error: git.eclipse.org does not know this committer, or this this committer cannot commit to this project (gid=8786 repo:eclipse.platform.ui): platform-releng-dev@eclipse.org. error: git.eclipse.org does not know this committer, or this this committer cannot commit to this project (gid=8786 repo:eclipse.platform.ui): sxenos. denied: You (remysuen@ca.ibm.com) cannot push changes that were not committed by you or members of your project. Please fix your repository, and see http://wiki.eclipse.org/Git for information on configuring your Git environment.
We need the following to happen: - Webmaster disables commit hook - Remy pushes all branches back to the repository - Webmaster re-enables the commit hook - Brian finds a new Git client
If you have you have recently fetched from the repo, please attach your .git/packed-refs: that contains the commit refs for the branches.
What is our backup strategy for these cases? Is it better to restore from the Foundation's backup or to execute the plan described by John in comment 2?
Created attachment 205756 [details] Remy's .git/packed-refs (In reply to comment #3) > If you have you have recently fetched from the repo, please attach your > .git/packed-refs: that contains the commit refs for the branches. Here is mine which should be the latest (relative to R4_development anyway), before Brian's push. R3_development may be old.
(In reply to comment #5) > Here is mine which should be the latest (relative to R4_development anyway), > before Brian's push. R3_development may be old. I guess the my push must have also triggered a GC as a lot of those refs point to invalid objects: $ git clone git://git.eclipse.org/gitroot/platform/eclipse.platform.ui.git git-platform.ui [...] $ cd git-platform.ui $ mv ~/Downloads/packed-refs.txt .git/packed-refs $ git branch -a error: refs/remotes/origin/Bug116920_investigation does not point to a valid object! error: refs/remotes/origin/Bug172193_investigation does not point to a valid object! error: refs/remotes/origin/Bug182059_investigation does not point to a valid object! error: refs/remotes/origin/Bug43657 does not point to a valid object! error: refs/remotes/origin/Bug_36957 does not point to a valid object! error: refs/remotes/origin/DS_WORK does not point to a valid object! error: refs/remotes/origin/EJP-v20020606branch does not point to a valid object! error: refs/remotes/origin/EJP_KeyBinding does not point to a valid object! error: refs/remotes/origin/EJP_LazyEditors does not point to a valid object! [...many many lines removed...] error: refs/tags/version3_2_lockdown_mergepoint20060608 does not point to a valid object! * master origin/HEAD origin/R3_6_maintenance origin/R3_7_maintenance origin/R3_development origin/R4_development origin/master So the important branches are all still there.
(In reply to comment #3) > If you have you have recently fetched from the repo, please attach your > .git/packed-refs: that contains the commit refs for the branches. My hypothesis, that Remy's packed-refs will contain the latest commits for the various branches, doesn't seem to hold: Remy's packed-refs has R3_6_maintenance's latest commit as 065d2d0 (dated 2011-05-10), whereas the latest that he pushed up (from EGit, I presume?) is commit a13f53d (dated 2011-08-12).
I have quite a new state (pulled yesterday) in case this helps.
(In reply to comment #8) > I have quite a new state (pulled yesterday) in case this helps. Dani, is your R3_development's branch's tip at commit 5b1f520a5d45522615b2eafa69b594231bc2e60f?
I have a repo it looks like I pulled Oct 21 06:47 PW
(In reply to comment #7) > My hypothesis, that Remy's packed-refs will contain the latest commits for the > various branches, doesn't seem to hold: Remy's packed-refs has > R3_6_maintenance's latest commit as 065d2d0 (dated 2011-05-10), whereas the > latest that he pushed up (from EGit, I presume?) is commit a13f53d (dated > 2011-08-12). Yes, I pushed using EGit.
Created attachment 205769 [details] git show-ref Branches in my clone (pulled on Friday evening): 5b1f520a5d45522615b2eafa69b594231bc2e60f refs/remotes/origin/R3_development 771ffa4adf120a2eda06e58d9aeaa9328437878d refs/remotes/origin/R4_development a13f53de2a0285b9427686372038e9e10660ba62 refs/remotes/origin/R3_6_maintenance c92f667efff2087a9dadd6f261b6196ffadde50a refs/remotes/origin/R3_7_maintenance Attaching the full $git show-ref
Here's my repo (pulled Friday, Oct 21, evening in Europe): http://dl.dropbox.com/u/9385300/eclipse.platform.ui_2011-10-23.zip It contains a few touched files (nothing important). I never created any branches or tags locally.
I had a look at Markus' refs, and we have different ones for one tag: < ff80c5f88a189b4a4e96c71dc8f5738ba9625368 refs/tags/v20110825-1421 --- > a9ae49dc16b219c6bdf901b303be5f5423804eef refs/tags/v20110825-1421 PW
> I had a look at Markus' refs, and we have different ones for one tag: Paul's a9ae49 is the parent of my ff80c5, so it looks like the v20110825-1421 tag got moved on the server, and I only checked out the repo after it was moved. Git operations don't update tags, so this is expected (and confirms that moving published tags is a no-go).
(In reply to comment #9) > (In reply to comment #8) > > I have quite a new state (pulled yesterday) in case this helps. > > Dani, is your R3_development's branch's tip at commit > 5b1f520a5d45522615b2eafa69b594231bc2e60f? Yes. But I'm behind with R4_development, so my repo is not the newest one.
The push has wiped out commits as well, which is why we can't just push the tags and branches back. We need the commit hooks disabled so we can push back the commits that goes with the tag/branch refs. PW
(In reply to comment #17) > We need the commit hooks disabled so we can push back the commits that goes > with the tag/branch refs. I have emailed webmaster@eclipse.org requesting intervention at their earliest convenience.
Is it possible to restore the repo from the server backup?
(In reply to comment #19) > Is it possible to restore the repo from the server backup? That could be another option. Certainly a lot safer than what we're doing.
> That could be another option. Certainly a lot safer than what we're doing. We can restore the repo to our latest snapshot _before_ 2011-10-21 16:31:50 EDT That would likely be somewhere around 10-21 3:00am EDT, so you would have "lost" all day Friday. Project lead, please confirm this is what you want.
I have a copy of the 7 Friday commits, Denis, please replace eclipse.platform.ui.git with the backup. PW
Then we need to disable the commit hooks long enough for me/remy to push back the 7 commits. PW
Doesn't the commit hook just ensure that the commits belong to a current committer? In this case I would assume the 7 commits on Friday were made by current committers so it should be fine...
(In reply to comment #24) > Doesn't the commit hook just ensure that the commits belong to a current > committer? In this case I would assume the 7 commits on Friday were made by > current committers so it should be fine... remy has them, and should be able to put them back quickly ... otherwise it's time spent tracking down individuals and getting them to re-commit their stuff in the correct order ... PW
(In reply to comment #24) > Doesn't the commit hook just ensure that the commits belong to a current > committer? In this case I would assume the 7 commits on Friday were made by > current committers so it should be fine... I also don't see why the commit hook is a problem.
(In reply to comment #26) > (In reply to comment #24) > > Doesn't the commit hook just ensure that the commits belong to a current > > committer? In this case I would assume the 7 commits on Friday were made by > > current committers so it should be fine... > > I also don't see why the commit hook is a problem. Got it: it checks that the person who pushes is the same as in the committer field. And since Remy doesn't want to reply all changes manually he also needs to be able to push changes which he's not registered as committer. Makes sense.
(In reply to comment #22) > I have a copy of the 7 Friday commits, Denis, please replace > eclipse.platform.ui.git with the backup. In case it was unclear, Paul is the project lead so Denis please go ahead [1]. I will separately make sure the Foundation database is updated since it still lists Boris as lead. [1] http://dev.eclipse.org/mhonarc/lists/platform-ui-dev/msg04980.html
We're running through tapes now. Please stand by.
Any word on this? I'm afraid to try anything else lest I destroy a new repo. PW
(In reply to comment #30) > Any word on this? I'm afraid to try anything else lest I destroy a new repo. Can we hold off on replacing the eclipse.platform.ui.git directory? Kim, could you try a build now? I've pushed my home repo successfully to git.eclipse.org/gitroot/platform/eclipse.platform.ui.git PW
Tape restores are done by our ISP. I'm not sure where they're at -- I'll ping them. Regardless, they are instructed to restore the files in a different location, so we won't overwrite anything before touching base with you.
I've started a build.
In case the commit hook was disable, please make sure it gets enabled again.
I've re-enabled the update hook.
The repo is up and running again. Marking as FIXED.
I'll just add the final fix. We took a cloned repo that was up to date from Thursday and pulled Friday's 7 commits into R4_development and R3_6_maintenance only. Denis disabled the commit hooks. Then we pushed all tags and pushed refs/remotes/origin/*:refs/heads/* Pushing the refs also pushed back the GCed commits. We should get that restored repo from the ISP and compare it with the public repo now, to confirm we've completely restored the repo. PW
(In reply to comment #32) > Tape restores are done by our ISP. In the end, our managed backup service did not automatically traverse NFS mounts. With the recent changes we'd done to our NFS servers, no code repos were being backed up. That is now fixed, and we'll verify with some test restores later this week. With much embarrassment, I humbly apologize for not being able to provide a restore.
