For the avoidance of doubt, I totally support what Austin and Johan are saying:
I find the current setup confusing too.
I'm totally persuaded of the merits of git bisect etc.
I am the opposite of a git power-user (a git weedy-user?). I will be content
to do whatever I'm told workflow-wise, pro
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.
Manuel
PS: While we are at it, why don't we just have the main repos on Git
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.
>
> Manuel
>
> PS:
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
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/
_
BTW, this could also be a basis for
solving another common pain point, that seems to afflict everyone:
"Validate fails. Was it me?"
Have the buildbots push only validating version-combinations
(using submodules to make this precise) into the repository
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
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
I think that Iavor is facing the same problems that I reported on this list on
May 15th. I also
see ghcpkg01 failing (when run during the validation) and passing (when run
separately). This
sometimes happens with other tests as well. Iavor, are you getting 'cahce is
out of date' error
when th
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
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.
>
Hi all,
The plugin mechanism gives access to the program in Core; this suffices for
many but not quite all purposes. Tools that need access to the original AST
can call typecheckModule directly, but of course this requires using the
GHC API directly. Moreover, even when using the GHC API directly
Uh. I'm sorry, I don't know why that email got sent, I was still
writing it. Please ignore it for now, will send the full version later :)
On Wed, Jun 5, 2013 at 12:14 PM, Edsko de Vries wrote:
> Hi all,
>
> The plugin mechanism gives access to the program in Core; this suffices
> for many b
Sorry for the earlier mishap, here's the full email.
Hi all,
The plugin mechanism gives access to the program in Core; this suffices for
many but not quite all purposes. Tools that need access to the original AST
can call typecheckModule directly, but of course this requires using the
GHC API dir
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
I don't know much about subtrees, but that might be another possibility?
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.
Geoff
On 06/05/2013 09:43 AM, Manuel M T Chakravarty wrote:
> I agre
Hi all,
This proposal is related to http://hackage.haskell.org/trac/ghc/ticket/1381,
which Simon Marlow closed through commit
https://github.com/ghc/ghc/commit/02c4ab049adeb77b8ee0e3b98fbf0f3026eee453.
The problem, in a nutshell, is "how do we terminate a code snippet started
with runStmt"? Befor
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
On Wed, Jun 05, 2013 at 12:17:07PM +0200, Jan Stolarek wrote:
> I think that Iavor is facing the same problems that I reported on this list
> on May 15th. I also
> see ghcpkg01 failing (when run during the validation) and passing (when run
> separately).
When you ran it separately, did you say
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 repositories/
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
> 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
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
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
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
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
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
Dom Silvério ANA CAROLINA PINTO COSTA, LISLY KATELLY DE PAULA MARTINS,
FRANCISCO HELSON DE LIMA NERES, PAULO RAFAEL PEREIRA SOARES, JOÃO CARLOS
MOREIRA DE CARVALHO, DAMIÃO JOVENAL DOS SANTOS, MARIA GORETTI LIMA FREIRE,
JANIMERY BARBOSA DE ABREU MELO. SHYSLAINE ARAÃJO BEZERRA, ARIANE SOARES
> 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/
30 matches
Mail list logo