Yep, I was going to recommend what Eric said, if you want to reapply them all. `git cherry-pick`, if given multiple arguments, will pick multiple commits in the same order you specify them. So you could say:
$ git cherry-pick 8da785d 130e93a 5910a1bc8 ... ... with all the commit hashes I previously reverted. That said, the main drawback here is re-applying these commits as they were will cause the build to break again, only to be fixed by a later commit, which hurts bisect. If you want, you can 'amend' the commits using rebase to make sure every individual commit builds. I'm not sure if anyone else has a strong opinion here, though! On Fri, May 15, 2015 at 12:16 PM, Eric Seidel <[email protected]> wrote: > You could use `git cherry-pick` > (http://git-scm.com/docs/git-cherry-pick) to re-apply each commit > individually. > > I think it would just be a simple > > $ git cherry-pick <commit> > > for each commit in the reverted list. cherry-pick accepts multiple > commits per invocation, but I'm not sure if it will squash them all > together into a single commit.. > > On Fri, May 15, 2015, at 09:51, Simon Peyton Jones wrote: >> Devs, Austin >> >> I've found out what the problem was, and fixed it. >> >> What is the right way to re-do all this? My thought: >> >> * git revert 3cf8ecd >> I think this will re-apply all my patches, in one go. >> (call this new path 'foogle') >> >> * apply the fix as a new patch >> >> * validate >> >> The history will look odd. In particular, if someone does 'git blame' >> then lots of unrelated changes will all map to 'foogle'. And 'foogle's >> commit message will say "revert a revert of 10 patches". Which is not >> helpful. >> >> Best would be to re-apply the patches one by one I suppose. How could I >> do that? >> >> Simon >> >> | -----Original Message----- >> | From: ghc-tickets [mailto:[email protected]] On Behalf >> | Of GHC >> | Sent: 14 May 2015 22:26 >> | Cc: [email protected] >> | Subject: Re: [GHC] #10359: Tuple constraint synonym led to asymptotic >> | performance lossage >> | >> | #10359: Tuple constraint synonym led to asymptotic performance lossage >> | -------------------------------------+-------------------------------- >> | -- >> | -------------------------------------+--- >> | Reporter: axch | Owner: >> | Type: bug | Status: >> | closed >> | Priority: normal | Milestone: >> | Component: Compiler | Version: 7.6.3 >> | Resolution: fixed | Keywords: >> | Operating System: Linux | Architecture: >> | x86_64 >> | Type of failure: Runtime | (amd64) >> | performance bug | Test Case: >> | Blocked By: | perf/should_run/T10359 >> | Related Tickets: | Blocking: >> | | Differential Revisions: >> | -------------------------------------+-------------------------------- >> | -- >> | -------------------------------------+--- >> | >> | Comment (by Austin Seipp <austin@…>): >> | >> | In [changeset:"3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4/ghc"]: >> | {{{ >> | #!CommitTicketReference repository="ghc" >> | revision="3cf8ecdc70cb295a2b9606080a1c7b5fa8eb16f4" >> | Revert multiple commits >> | >> | This reverts multiple commits from Simon: >> | >> | - 04a484eafc9eb9f8774b4bdd41a5dc6c9f640daf Test Trac #10359 >> | - a9ccd37add8315e061c02e5bf26c08f05fad9ac9 Test Trac #10403 >> | - c0aae6f699cbd222d826d0b8d78d6cb3f682079e Test Trac #10248 >> | - eb6ca851f553262efe0824b8dcbe64952de4963d Make the "matchable- >> | given" >> | check happen first >> | - ca173aa30467a0b1023682d573fcd94244d85c50 Add a case to >> | checkValidTyCon >> | - 51cbad15f86fca1d1b0e777199eb1079a1b64d74 Update haddock submodule >> | - 6e1174da5b8e0b296f5bfc8b39904300d04eb5b7 Separate transCloVarSet >> | from fixVarSet >> | - a8493e03b89f3b3bfcdb6005795de050501f5c29 Fix imports in HscMain >> | (stage2) >> | - a154944bf07b2e13175519bafebd5a03926bf105 Two wibbles to fix the >> | build >> | - 5910a1bc8142b4e56a19abea104263d7bb5c5d3f Change in capitalisation >> | of error msg >> | - 130e93aab220bdf14d08028771f83df210da340b Refactor tuple >> | constraints >> | - 8da785d59f5989b9a9df06386d5bd13f65435bc0 Delete commented-out >> | line >> | >> | These break the build by causing Haddock to fail mysteriously when >> | trying to examine GHC.Prim it seems. >> | }}} >> | >> | -- >> | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10359#comment:9> >> | GHC <http://www.haskell.org/ghc/> >> | The Glasgow Haskell Compiler >> | _______________________________________________ >> | ghc-tickets mailing list >> | [email protected] >> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets >> _______________________________________________ >> ghc-devs mailing list >> [email protected] >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
