hg strip will fix it, but you have to do it on the repository on daystrom directly (in addition to yours). Git has a push --force flag. Does mercurial have something similar? On my ipad so hard for me to do any poking around.
On Jun 15, 2013, at 1:21 PM, Nilay Vaish <[email protected]> wrote: > I updated the stable branch, but I made a mistake while pushing the changes. > I was trying to push just one changeset to test if things work correctly. I > did not mention the revision id for the changeset that I wanted to push. > Hence now gem5-stable repo is at the same point as gem5 repo. > > I am not aware of any way for rolling back to some particular point in past. > Should we leave it as is? Or can we do something about it? > > > This is exactly what happened: > ------------------------------------------------------------------------- > [nilay@ribera] (10)$ hg update -r f58f93f1656c > 1498 files updated, 0 files merged, 177 files removed, 0 files unresolved > [nilay@ribera] (11)$ hg tip > changeset: 9756:0b4a08751b42 > tag: tip > user: Nilay Vaish <[email protected]> > date: Thu Jun 13 07:24:25 2013 -0500 > summary: config: Do not instantiate membus when using ruby > > [nilay@ribera] (12)$ hg log | less > [nilay@ribera] (13)$ hg summary > parent: 9074:f58f93f1656c > ARM: Fix issue with predicted next pc being wrong because of advance() > ordering. > branch: default > commit: 1042 unknown (clean) > update: 682 new changesets (update) > mq: 38 unapplied > [nilay@ribera] (14)$ > [nilay@ribera] (14)$ > [nilay@ribera] (14)$ > [nilay@ribera] (14)$ > [nilay@ribera] (14)$ hg push ssh://[email protected]/gem5-stable > pushing to ssh://[email protected]/gem5-stable > The authenticity of host 'repo.gem5.org (141.212.106.70)' can't be > established. > RSA key fingerprint is f8:fc:93:39:96:19:22:cd:df:71:ab:24:8d:46:41:74. > Are you sure you want to continue connecting (yes/no)? yes > Enter passphrase for key '/u/n/i/nilay/.ssh/id_rsa': > searching for changes > remote: Warning: Permanently added 'repo.gem5.org' (RSA) to the list of known > hosts. > remote: adding changesets > remote: adding manifests > remote: adding file changes > remote: added 683 changesets with 6830 changes to 1633 files > remote: notify: sending 1 subscribers 683 changes > ---------------------------------------------------------------------------- > > > -- > Nilay > > On Fri, 14 Jun 2013, Nilay Vaish wrote: > >> So I am going to update the gem5-stable repo over the weekend to the >> following revision: >> >> changeset: 9644:07352f119e48 >> user: Ali Saidi <[email protected]> >> date: Mon Apr 22 13:20:31 2013 -0400 >> summary: cpu: fix a switching issue with the o3 cpu. >> >> If we see any major bugs being reported by users of gem5-stable, I'll try to >> see if any patches committed after 07352f119e48 can resolve those and push >> them to the stable repo. >> >> -- >> Nilay >> >> >> On Fri, 24 May 2013, Steve Reinhardt wrote: >> >>> Just to add my two cents... as Ali said, Nilay's points are true but he is >>> not the first to raise them; we have had multiple lengthy discussions on >>> this list on defining an appropriate policy for regularly updating >>> gem5-stable, only to have them all fall apart when it came to following >>> through. >>> I'll differ semantically with Nilay and Andreas on a few points though. >>> First, gem5-stable is stable in the sense that it changes much less >>> frequently than gem5 (much much much less... too much less... but it does >>> fit the definition of stable). Second, I'd say that gem5-stable is not a >>> "separate repository", it really is just a specific revision of the gem5 >>> tree. It's another clone of the same repo as gem5 (and is updated just by >>> pulling from gem5 as Ali pointed out). It only looks like a separate >>> repository given the way we expose it on the web site. >>> I'm all for giving it another go... I don't think we even need to invent a >>> new policy, just pull out the one we agreed on last time, but find a way to >>> make it happen. If we conclude that we're incapable of implementing a >>> policy (a reasonable conclusion based on history) and it's better to get >>> rid of it than to leave it to get so stale, I'm OK with that too. >>> Steve >>> On Thu, May 23, 2013 at 8:56 PM, Ali Saidi <[email protected]> wrote: >>>> You should be able to just push to it. >>>> Something like >>>> hg clone http://repo.gem5.org/gem5 >>>> cd gem5 >>>> hg update -r <rev that is good/stable/whatever> >>>> hg push ssh://[email protected]/gem5-stable >>>> Ali > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
