> Could you send out the commit ID? This may mess up my SE/FS tree if I've> > merged that change over. It's 330f8109b199.
Unfortunately, in my opinion, we really have to do this. The repo was about 90MB before this and 220MB after that change. The change that undoes the mistake would make the repo 350MB. That's an enormous waste. Dealing with it will basically require stripping that change out. Mercurial doesn't support that kind of maneuver easily. I know of two options, both start with stripping the offending changeset and all its children in the main tree on daystrom. 1) Then I believe that you can add the correct changeset as a sibling of the bad one (by updating to e66a566f2cfa and then committing), you'd then use rebase to move everything over to the new child of e66a566f2cfa. I think it should go smoothly since there shouldn't be any conflicts. 2) An alternative (that might be equivalent) that I am certain will work is to use "hg export" to export 330f8109b199 and all of its children into your patch directory (and manually add them to the series file). You'd then strip 330f8109b199 and all of its children, then you'd replace 330f8109b199 with the correct changeset and reapply all patches. After you've done one of these things, you'd push to the main repo and then the main repo is correct. For anyone that wants to pull from the new main repo, they'd have to strip the bad changeset and its descendants before the pull. If you accidentally didn't do that, you'd wind up with two heads and a merge request. If you did the merge you'd get the badness back, but the commit hook I have will prevent it from getting back into the main tree. Gabe, in your case, it may simply be a matter of stripping all of the descendents (including any merges that you did) and just pulling and re-merging. If you have any useful merging that you'd rather not re-do, you can use export to save those and then manually reapply. Yes, this is all some relatively technical surgery on the mercurial tree, but it'd be a shame to have an extra 260 MB added to every gem5 checkout and download. (It would waste several gigabytes on my laptop which is already full and it would make all downloads take 4 times longer.) Nate _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
