evs [mailto:ghc-devs-boun...@haskell.org] *On Behalf 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 toda
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, if
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 anyt
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 pl
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 I
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* explai
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
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
http://www.haskell.org/mailman/l
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 compi
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
>>> submod
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?
Submodul
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 wi
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
On 06/06/2013 02:42 AM, Kazu Yamamoto (山本和彦) wrote:
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 n
> 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:
http://nvie.com/
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
Hi Austin,
On Wed, Jun 05, 2013 at 10:47:27AM -0500, Austin Seipp wrote:
> It's *part* of mainline git, but it is not installed with git. It's
> part of git's "contrib" functionality package which requires that your
> package maintainer be gracious enough to include it and install it by
> default
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 t
On Wed, Jun 5, 2013 at 10:20 AM, Daniel Trstenjak
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 installed with git. I
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
> 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 thi
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 reposi
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 repositories/
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 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 hand
t;>
>>
>>
>> | -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: h
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 d
David Terei :
> On 5 June 2013 01:43, Manuel M T Chakravarty 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 tree would be a serious benefit IMO.
>
When I was fiddling with having to rollback everything to a known good
state I patched sync-all to checkout all the repos to the state they were
in on a certain date, it's pretty naive, but it should be usable for doing
manual bisecting at least. I can't find the old mailing list archives, so I
att
On 06/05/2013 10:10 AM, David Terei wrote:
On 5 June 2013 01:43, Manuel M T Chakravarty 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 tree would be a
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 abl
kell.org/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 subm
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/
_
On Wed, Jun 5, 2013 at 5:10 PM, David Terei wrote:
> On 5 June 2013 01:43, Manuel M T Chakravarty 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 who
c/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
kell.org/trac/ghc/wiki/Repositories, and the linked page
> http://hackage.haskell.org/trac/ghc/wiki/Repositories/Upstream.
>
> Simon
>
>
>
> | -Original Message-
> | From: ghc-devs-boun...@haskell.org [mailto:ghc-devs-boun...@haskell.org]
> | On Behalf Of Austin
han 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 with it. And it's entirely possible submodules are
|
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 for some reason that I'm not aware of which is a
show-stopper.
However, the notion of i
On Tue, Jun 4, 2013 at 7:05 PM, 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? It's
> terrible. I'm frankly surprised we've even bee
(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.
-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 Y
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" wrote:
> Unfortunately we don't use submodules for all repos e.g. base. This makes
> it very hard to accurately check out a previous s
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 wrote:
> Hi,
>
> Andreas and I found that the new IO manager is not working properly in
43 matches
Mail list logo
