
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@haskell.org] On Behalf
| Of GHC
| Sent: 14 May 2015 22:26
| Cc: ghc-tickets@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

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

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

OK thanks. I have cherry-picked, combined, validated, and pushed. Should be good now.
Simon
| -----Original Message-----
| From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of
| Austin Seipp
| Sent: 15 May 2015 18:25
| To: Eric Seidel
| Cc: ghc-devs@haskell.org
| Subject: Re: Revert revert revert
|
| 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
participants (3)
-
Austin Seipp
-
Eric Seidel
-
Simon Peyton Jones