Revert revert revert

[Austin Seipp]

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 <eric at seidel.io> 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:ghc-tickets-bounces at haskell.org] On Behalf
>> |  Of GHC
>> |  Sent: 14 May 2015 22:26
>> |  Cc: ghc-tickets at haskell.org
>> |  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
>> |  ghc-tickets at haskell.org
>> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs



-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/