Re: git question

[Nathan Bouscal]

You can unstage a change using 'git reset', e.g. 'git reset utils/haddock'.
As part of an interactive rebase, my approach would be to 'edit' the commit
in question, then use 'git reset HEAD^' to undo that commit but keep the
changes in your working directory (but unstaged), then either stage the
changes you do want to keep using 'git add', or stage everything using 'git
add -A' and then unstage the haddock change with 'git reset utils/haddock',
followed finally by creating a new commit and continuing the rebase.
Hope this helps.


-Nathan

On Fri, Sep 30, 2016 at 12:21 PM, Simon Peyton Jones via ghc-devs <
ghc-devs@haskell.org> wrote:

> Ah yes, but it had a lot of OTHER stuff that I wanted. It was only the
> accidental change to a submodule that I wanted to kill off.
>
>
>
> *From:* Harendra Kumar [mailto:harendra.ku...@gmail.com]
> *Sent:* 30 September 2016 12:20
> *To:* Simon Peyton Jones 
> *Cc:* Edward Z. Yang ; ghc-devs 
> *Subject:* Re: git question
>
>
>
> When you do 'git rebase -i', to exclude the commit you can just delete
> that commit from the list of commits.
>
>
>
> -harendra
>
>
>
> On 30 September 2016 at 16:40, Simon Peyton Jones via ghc-devs <
> ghc-devs@haskell.org> wrote:
>
> Thanks... that worked.
>
> Somehow it ought to be possible to un-stage the haddock change rather that
> carefully undo it manually.  But it worked so I'm not complaining!
>
> Thank you
>
> Simon
>
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Edward Z. Yang
> |  Sent: 30 September 2016 11:53
> |  To: ghc-devs 
> |  Subject: Re: git question
> |
> |  Get to the commit you want to edit, then
> |
> |  cd utils/haddock
> |  git checkout 073d899a8f94ddec698f617a38d3420160a7fd0b
> |  cd ../..
> |  git commit --amend -a
> |
> |  Excerpts from Simon Peyton Jones via ghc-devs's message of 2016-09-30
> |  10:47:24 +:
> |  > Friends
> |  > I have a batch of several commits lined up on my local machine,
> |  validated, and ready to push to the master.
> |  > But one seems to have accidentally got
> |  >
> |  > diff --git a/utils/haddock b/utils/haddock
> |  >
> |  > index 073d899..a3309e7 16
> |  >
> |  > --- a/utils/haddock
> |  >
> |  > +++ b/utils/haddock
> |  >
> |  > @@ -1 +1 @@
> |  >
> |  > -Subproject commit 073d899a8f94ddec698f617a38d3420160a7fd0b
> |  >
> |  > +Subproject commit a3309e797c42dae9bccdeb17ce52fcababbaff8a
> |  > I did not want to meddle with Haddock.
> |  > Question: how can I remove this change from my commit?  I know how
> |  to do git rebase –interactive, and I can aske to “edit” that commit…
> |  but what then?
> |  > Thanks
> |  > Simon
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
>
> |  https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.h
> |  askell.org
> 
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
> |  devs=01%7C01%7Csimonpj%40microsoft.com
> 
> %7C6d4ef4135a94439fb54708d3
> |  e91ffd21%7C72f988bf86f141af91ab2d7cd011db47%7C1=rNLWdOI3SNnfXPYj
> |  PMHXC8U1l5sxI3eOwjHWaKpsBaY%3D=0
>
> ___
> 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
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How, precisely, can we improve?

[Nathan Bouscal]

On Mon, Sep 26, 2016 at 2:27 AM, Richard Eisenberg 
wrote:
>
>
> "Accept PRs on GitHub" *is* an answer to this question, but one we have
> revisited several times in recent memory. (I believe https://mail.haskell.
> org/pipermail/ghc-devs/2015-September/009744.html is the most recent.)
> Perhaps we can revisit this yet again, but it would be great if new
> technical content can be injected into the debate. I hope the rejection of
> the proposal linked there is not considered "dismissive", as the proposal
> generated vigorous debate -- the opposite of dismissiveness. (For what it's
> worth, I'm weakly in favor of accepting PRs on GitHub. However, I have no
> experience setting up or maintaining infrastructure for an open source
> project and have happily deferred to those who have such experience and who
> have come out against this idea.)
>

It may be worth pointing out that one of the most common objections in that
debate was GitHub's code review process, and in the time since that process
has been completely overhauled

.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: wither the Platform

[Nathan Bouscal]

Richard: The problem isn't the age itself, but rather the compatibility
problems that age introduces. It can be quite difficult as a new user to
get all of the libraries you want to use to play well with the platform.
There's usually a way to make it work if you know what you're doing, but
the platform is largely targeted at those who don't. This is particularly
bad because library compatibility problems are inherently annoying to
solve, or at least they feel that way to me.


I think Gershom framed the problem well. From the discussion, it sounds
like there are a lot of potential solutions, mostly in the category of
re-conceive the platform.

On Mon, Mar 23, 2015 at 9:32 AM, Miëtek Bak mie...@bak.io wrote:

 On 2015-03-22, at 15:59, Michael Snoyman mich...@snoyman.com wrote:

  2. A method for installing GHC and build tools. I personally think that
 it makes sense to separate out this aspect of the platform from all others.
 MinGHC is an example of such a project: a minimal set of functionality for
 bootstrapping a more complete Haskell development environment.
  3. Prebuilt binary package databases. As I've mentioned in the past, and
 others have here, there are problems with the current approach of putting
 the packages in the global package database. I'd personally rather see this
 aspect of the platform give way to more robust solutions.


  I think a smaller task force dedicated to improving the tooling
 situation is the best next step, and I'd be happy to kick off such an
 effort with other interested individuals.

 I’d be very happy to contribute to this effort.  In fact, I’ve already
 spent some of time addressing these issues.

 Halcyon already provides a method for installing GHC, cabal-install,
 build-tools, and other Haskell programs — on OS X, and many Linux
 distributions.  FreeBSD and Windows are on the roadmap.

 Additionally, Halcyon allows you to declare native OS libraries as
 build-time (or run-time…) dependencies for Haskell programs.  They will be
 installed into a user-controlled directory, by wrapping around the native
 OS package manager.

 Currently, this is supported on Debian-based and RedHat-based Linux
 distributions, which partially implements a long-standing cabal-install
 feature request:
 https://github.com/mietek/halcyon/issues/38
 https://github.com/haskell/cabal/issues/571

 See the Haskell Language source code for an example:
 https://halcyon.sh/examples/#haskell-language

 See the Halcyon reference for details:
 https://halcyon.sh/reference/#halcyon_sandbox_extra_os_packages
 https://halcyon.sh/reference/#halcyon_extra_os_packages


 --
 Miëtek
 https://mietek.io



 ___
 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