Hi all,
I just reread this thread again. Is this one of these situations where *almost
everyone agrees, but the fix just didn't happen*?
In particular, there is still no formal relationship between versions of
the compiler and versions of the testsuite that tests it -- that seems odd!
Can we
Simon and I discussed this a little today. I think there are several
legitimate points made throughout the threads here, but the problem is
clear: consistent builds are difficult, if not legitimately impossible.
That's a very big problem.
Right now, it is far too late into release cycle to do
August 2013 20:31
To: Ryan Newton
Cc: ghc-devs@haskell.org; Edward Kmett
Subject: Re: how to checkout proper submodules
Simon and I discussed this a little today. I think there are several legitimate
points made throughout the threads here, but the problem is clear: consistent
builds are difficult
Of *Austin
Seipp
*Sent:* 22 August 2013 20:31
*To:* Ryan Newton
*Cc:* ghc-devs@haskell.org; Edward Kmett
*Subject:* Re: how to checkout proper submodules
** **
Simon and I discussed this a little today. I think there are several
legitimate points made throughout the threads here
Hi,
We misunderstood that the new IO manager was not working
properly. This is our fault. We confirmed that it is working
well. Sorry for bothering you, guys.
Anyway, I believe we need a way to check out proper submodules as many
others said.
--Kazu
Hi,
Andreas and I found that the new IO
Hi Geoffrey,
I am of the opinion that major feature branches should be rebased
*and* that they should then be merged with --no-ff.
I totally agree with you. :-)
--Kazu
___
ghc-devs mailing list
ghc-devs@haskell.org
Hi,
I think you've to differentiate the case of merging a feature branch
into the master branch and the case of merging a local with a remote
branch, like just calling git pull/push on the master branch.
I just wanted to say that first forward merge loses information about
which sequence of
On 08/06/13 08:38, Geoffrey Mainland wrote:
On 06/06/2013 09:44 PM, Simon Marlow wrote:
On 05/06/13 16:59, Ian Lynagh wrote:
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we
On 06/06/2013 09:44 PM, Simon Marlow wrote:
On 05/06/13 16:59, Ian Lynagh wrote:
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we are in this situation of half
submodules, half
On 5 Jun 2013, at 16:47, Austin Seipp wrote:
testsuite and base are also useful for other compilers,
such as nhc98 (and indeed, nhc uses base itself.)
Useful, perhaps, but not actually used in practice. Since the base library
repo moved from darcs to git, I think that ghc is the only
Daniel,
On Wed, 2013-06-05 at 15:49 +0200, Daniel Trstenjak wrote:
Hi Nicolas,
On Wed, Jun 05, 2013 at 03:27:09PM +0200, Nicolas Trangez wrote:
As my experience with submodules is positive (though limimted), could
you elaborate on the difficulties/hassle here?
If you would like to
Hi Kazu,
On Thu, Jun 06, 2013 at 10:42:03AM +0900, Kazu Yamamoto wrote:
Please read A successful Git branching model to know why fast-forward
is not used recently.
I think you've to differentiate the case of merging a feature branch
into the master branch and the case of merging a local with
On 05/06/13 16:59, Ian Lynagh wrote:
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we are in this situation of half
submodules, half random-floating-git-repository-checkouts?
| Cc: ghc-devs@haskell.org
| Subject: Re: how to checkout proper submodules
|
| I absolutely agree here, FWIW. We should only do this if there is a
| clear consensus on doing so and everyone doing active development is
| comfortable with it. And it's entirely possible submodules are
| inadequate
/wiki/Repositories/Upstream.
Simon
| -Original Message-
| From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
| On Behalf Of Austin Seipp
| Sent: 05 June 2013 07:35
| To: Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: Re: how to checkout proper
: 05 June 2013 07:35
| To: Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: Re: how to checkout proper submodules
|
| I absolutely agree here, FWIW. We should only do this if there is a
| clear consensus on doing so and everyone doing active development is
| comfortable
David Terei wrote:
Either way, I'm glad git bisect may soon work.
Having git bisect work on the GHC tree would be a plus!
Erik
--
--
Erik de Castro Lopo
http://www.mega-nerd.com/
g/trac/ghc/wiki/Repositories/Upstream.
Simon
| -Original Message-
| From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
| On Behalf Of Austin Seipp
| Sent: 05 June 2013 07:35
| To: Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: Re: how to checkout proper submodu
For me the biggest plus of switching to submodules would be keeping GHC and
testsuite in sync. If
there are any reasons not to change in-tree library repos to submodules, then I
would at least
want testsuite to be changed to a submodule.
I also use github for my daily work on GHC and being
On 06/05/2013 10:10 AM, David Terei wrote:
On 5 June 2013 01:43, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote:
I agree with Austin and Johan. It's a bizarre setup. Submodules have their
pain points (which we already have to deal with), but the ability to
properly snapshot and branch the
David Terei davidte...@gmail.com:
On 5 June 2013 01:43, Manuel M T Chakravarty c...@cse.unsw.edu.au wrote:
I agree with Austin and Johan. It's a bizarre setup. Submodules have their
pain points (which we already have to deal with), but the ability to properly
snapshot and branch the whole
I very much support moving to all-submodules. In fact, I argued for
all-submodules when we made the half-submodules transition last
year. Being able to easily check out a consistent and complete source
code tree in a repeatable way is extremely important.
Checking out by date works if you have
/Upstream.
Simon
| -Original Message-
| From: ghc-devs-boun...@haskell.org
[mailto:ghc-devs-boun...@haskell.org]
| On Behalf Of Austin Seipp
| Sent: 05 June 2013 07:35
| To: Johan Tibell
| Cc: ghc-devs@haskell.org
| Subject: Re: how to checkout proper submodules
|
| I absolutely
Hi Geoffrey,
I don't know much about subtrees, but that might be another possibility?
the main point about subtrees is, that you've just one repository and
you're merging a directory of this repository with 'git subtree' with
some other git repository.
subtrees and submodules both try to
On Wed, 2013-06-05 at 15:24 +0200, Daniel Trstenjak wrote:
because a lot of workflows (like branching) are such
a hassle with submodules.
As my experience with submodules is positive (though limimted), could
you elaborate on the difficulties/hassle here?
Thanks,
Nicolas
Hi Nicolas,
On Wed, Jun 05, 2013 at 03:27:09PM +0200, Nicolas Trangez wrote:
As my experience with submodules is positive (though limimted), could
you elaborate on the difficulties/hassle here?
If you would like to develop some kind of feature which involves
changes on multiple
I'm back after sleep.
A few points:
1) Subtree is - in my opinion - basically not an option. It has a nice
workflow from the small amount of time I spent with it. But it's not
installed by default with git, it's unclear if it ever will be.
Although subtree gives the appearance of a unified
1) We could now delete ./sync-all if this happened.
In that case I would vote for replacing sync-all with a script that aids in
managing branches in
multiple subrepos. I implemented such a script for myself in a very ad hoc way.
Having something
more robust would be great.
2) One thing this
Hi Austin,
On Wed, Jun 05, 2013 at 09:41:56AM -0500, Austin Seipp wrote:
But it's not installed by default with git, it's unclear if it ever will be.
I think subtree has been part of git since 1.7.x .
I have just installed the default git package (git 1.8.1.2) of Ubuntu
13.04 and the subtree
On Wed, Jun 5, 2013 at 10:20 AM, Daniel Trstenjak
daniel.trsten...@gmail.com wrote:
I think subtree has been part of git since 1.7.x .
I have just installed the default git package (git 1.8.1.2) of Ubuntu
13.04 and the subtree command is just there.
It's *part* of mainline git, but it is not
On Tue, Jun 04, 2013 at 09:05:58PM -0500, Austin Seipp wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we are in this situation of half
submodules, half random-floating-git-repository-checkouts?
Submodules are very handy for libraries that
I think that testsuite should be included in the main GHC repo. I don't recall
any other project
that has its tests placed in a separate repository. The nhc argument doesn't
convince me - after
all, most test that are added nowadays are GHC specific.
Janek
There are a lot of things to recommend moving to github. I do hate
(non-empty) merge commits, though, so I'm not a fan of github's pull
request mechanism.
Please read A successful Git branching model to know why fast-forward
is not used recently.
Git flow:
Unfortunately we don't use submodules for all repos e.g. base. This makes
it very hard to accurately check out a previous state and bisect errors
unfortunately.
On Tue, Jun 4, 2013 at 6:07 PM, Kazu Yamamoto k...@iij.ad.jp wrote:
Hi,
Andreas and I found that the new IO manager is not working
Is the way forward then to manually bisect by timestamp? Perhaps there are
scripts out there to assist with stuck a task.
On Jun 4, 2013 8:47 PM, Johan Tibell johan.tib...@gmail.com wrote:
Unfortunately we don't use submodules for all repos e.g. base. This makes
it very hard to accurately check
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/06/13 02:46, Johan Tibell wrote:
Unfortunately we don't use submodules for all repos e.g. base. This
makes it very hard to accurately check out a previous state and
bisect errors unfortunately.
On Tue, Jun 4, 2013 at 6:07 PM, Kazu
(Warning: incoming answer, followed by a rant.)
Base is not a submodule, meaning that there is essentially no way to
automatically check it back out to the exact same state it was in,
given some specified GHC commit - the commit IDs are not tracked.
At this point, you are basically on your own.
On Tue, Jun 4, 2013 at 7:05 PM, Austin Seipp ase...@pobox.com wrote:
I know we had this discussion sometime recently I think, but can
someone *please* explain why we are in this situation of half
submodules, half random-floating-git-repository-checkouts? It's
terrible. I'm frankly surprised
38 matches
Mail list logo
