Closed Bug 1107988 Opened 10 years ago Closed 9 years ago

Find way of making docs merge not have happened

Categories

(Bugzilla :: Bugzilla-General, defect)

Product:
Bugzilla
Component:
Bugzilla-General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: gerv, Unassigned)

Details

I merged my docs branch in, instead of doing a squash commit, and now the revision history is full of "WIP" commits. This extends to bzr and cvs as well. This bug tracks the effort to fix this.

Gerv
git-to-brz mirroring on trunk disabled, per glob
dylan's working on fixing up git.  we need to fix the repo and post to bugzilla-dev with instructions on how to fix a busted commit.

we've disabled mirroring of master to bzr while this happens.

the easiest thing here may be to just stop mirroring trunk to bzr and cvs.
dkl's working on landfill to swing the demo installs to pull from git instead of bzr.

this will also mean that bonsai will no longer see updates from bugzilla, however both git.mozilla.org and github have commit history and blame UIs.
glob: thanks for driving this.

"busted commit" -> "busted checkout"?

dkl: follow these instructions:
http://bugzilla.readthedocs.org/en/latest/installing/migrating-from-bzr.html
Not because you need to, but because it's a good opportunity to test them.

Gerv
I have done a git push -f to master. Action is required on developers that have a checkout with the offending history. 

First, do a git fetch to get the new origin/master reference:
$ git fetch origin

First, commit any changes you have made.
Next:
$ git rebase -i origin/master

This will open up your editor with all the commits that you have made + the ones
Delete all the "pick ..." lines that are not *YOUR* changes.

If you have made no changes, delete all the lines with a single word:
noop

Save and quit, and your checkout should be able to communicate with master once again.
Dylan: thanks for fixing this!

Your instructions have two "First"s... but I can confirm that they worked for me, done in the order given. There is no need to be _on_ the master branch when executing them, as far as I can see.

You've kept the OldBugMove commit but removed the docs commit, right? When would it be appropriate for me to check in a squash commit with the new docs? (Or does someone else want to do that, given what happened? :-)

Gerv
While you are on it, could you also remove buggy commits done by gerv for bug 919122 and bug 317021 from git history?

10 days ago 	Matt Selsky	Bug 317021 - improve description of bz_canusewhine... 
10 days ago 	Gervase Markham	Revert "Bug 317021 - improve description of bz_canusewh...
11 days ago 	Matt Selsky	Bug 317021 - improve description of bz_canusewhine... 	
11 days ago 	Matt Selsky	Bug 919122 - support for sourceforge.net Allura bugs... 
11 days ago 	Gervase Markham	Oops. Revert commit with bogus message #2. paperbag... 	
11 days ago 	Gervase Markham	Oops. Revert commit with bogus message #1. paperbag... 	
11 days ago 	Matt Selsky	Are you sure you want to check in on branch master 	
11 days ago 	Matt Selsky	Are you sure you want to check in on branch master
And also:

6 days ago 	Gervase Markham	Bug 1093616 - Revert "Update permissions of replyrc... 
6 days ago 	Gervase Markham	Update permissions of replyrc to whatever checksetup...
LpSolit: I think it's too late for that, unless dylan wants to do more surgery, another push -f, and get me and others to rebase their repos a second time.

Gerv
(In reply to Byron Jones ‹:glob› from comment #2)
> the easiest thing here may be to just stop mirroring trunk to bzr and cvs.
> dkl's working on landfill to swing the demo installs to pull from git
> instead of bzr.

I have update landfill to pull changes from git for bugzilla-tip at this time. The old bzr based directory is moved but not deleted.

Hopefully landfill is backed up so I don't lose my changes :)

dkl
(In reply to David Lawrence [:dkl] from comment #9)
> (In reply to Byron Jones ‹:glob› from comment #2)
> > the easiest thing here may be to just stop mirroring trunk to bzr and cvs.
> > dkl's working on landfill to swing the demo installs to pull from git
> > instead of bzr.
> 
> I have update landfill to pull changes from git for bugzilla-tip at this
> time. The old bzr based directory is moved but not deleted.

Oh and to add, once everything seems like it is working fine, I will do the same for the other stable demo installs as well.

dkl
(In reply to Gervase Markham [:gerv] from comment #8)
> LpSolit: I think it's too late for that, unless dylan wants to do more
> surgery, another push -f, and get me and others to rebase their repos a
> second time.

Why not? The goal of this bug is to fix the commit history. Asking devs to do a rebase a 2nd time is not the most critical part at this point.
I spoke to glob, dkl and dylan at the All Hands meeting, and they declined to make this additional change.

The impact caused by those few bogus commits is nothing compared to the impact of the bogus merge. I'm sure you can overlook them when looking back through history.

They've reopened the tree, and more patches have started to be committed.

Gerv
bzr.mozilla.org is finally cleaned up and mirroring back in place. shout if you see something incorrect. old mess is backed up in a tarball in /root.
Thanks, fubar!

Is there more to do here?

CVS was mirrored from bzr, right? Is that mirroring still disabled? If not, is it cleaned up?

Gerv
I think we're safe in closing this bug.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
(In reply to Gervase Markham [:gerv] from comment #14)
> CVS was mirrored from bzr, right? Is that mirroring still disabled? If not,
> is it cleaned up?

It's not cleaned up, no.
(In reply to Frédéric Buclin from comment #16)
> It's not cleaned up, no.

OK. I assume, unless anyone says different, that we've decided not to clean it up because no-one should be pulling from trunk on CVS any more, so we've frozen the server.

If that's wrong, someone shout.

Gerv
(In reply to Gervase Markham [:gerv] from comment #17)
> OK. I assume, unless anyone says different, that we've decided not to clean
> it up because no-one should be pulling from trunk on CVS any more, so we've
> frozen the server.

The CVS server is not frozen. New checkins still appear in CVS. But we have a 5 months long mess in the CVS history, which is a pain when using Bonsai.
(In reply to Frédéric Buclin from comment #18)
> (In reply to Gervase Markham [:gerv] from comment #17)
> > OK. I assume, unless anyone says different, that we've decided not to clean
> > it up because no-one should be pulling from trunk on CVS any more, so we've
> > frozen the server.
> 
> The CVS server is not frozen. New checkins still appear in CVS. But we have
> a 5 months long mess in the CVS history, which is a pain when using Bonsai.

Just to add my 2 cents here. Of course we are all sorry that this happened and valuable lessons were learned. But noone, including myself, has the available time and resources right now to do clean up on a version control system that will be decommissioned any week now once 5.0 is released. Just unfortunate timing in that it happened when it did. Let's let this one die so we can spend the time needed to move forward with 5.0 and beyond.

dkl
You need to log in before you can comment on or make changes to this bug.