Quoting nathan binkert <[email protected]>:
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
Yeah, I think it's definitely something we should do, I'm just not
looking forward to the process of actually doing it.
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
