Re: Working in my own branch with changes in submodules

Alejandro Serrano Mena writes: > Dear GHC devs, > I am currently working on my own fork of GHC ( > https://gitlab.haskell.org/trupill/ghc), and as part of it I need to do > some changes to the Cabal and haskeline libraries. However, since they are > in submodules, I am not sure

Working in my own branch with changes in submodules

Dear GHC devs, I am currently working on my own fork of GHC ( https://gitlab.haskell.org/trupill/ghc), and as part of it I need to do some changes to the Cabal and haskeline libraries. However, since they are in submodules, I am not sure about how I can commit those changes, share them with others

Re: GitLab forks and submodules

. Here's what I do: - Clone gitlab/ghc/ghc ("origin") - Add gitlab/fork/ghc ("fork", the fork I want to build) - git fetch --all - git checkout fork/branch - git submodule update --init For whatever reason git tries to fetch submodules from "fork" instead of "o

Re: GitLab forks and submodules

Moritz Angermann writes: > Alright let me add some example that is really painful with submodules. > > Say I have a custom ghc fork angerman/ghc, because I really don't want > to overload CI with all my stupidity and I *know* I'd forget to mark > every commit with [skip ci] or som

Re: GitLab forks and submodules

Ömer Sinan Ağacan writes: >> As I mention in the documentation, those with commits bits should feel >> free to push branches to ghc/ghc. > > This is sometimes not ideal as it wastes GHC's CI resources. For example I > make > a lot of WIP commits to my work branches, and I don't want to keep CI

Re: GitLab forks and submodules

Ömer Sinan Ağacan writes: > while making the case of contributing patches with submodule changes more > difficult > > I don't understand this, can you give an example of what absolute paths make > harder? > > Looking at the wiki pages and scripts we need to make relative paths work for >

Re: GitLab forks and submodules

Alright let me add some example that is really painful with submodules. Say I have a custom ghc fork angerman/ghc, because I really don't want to overload CI with all my stupidity and I *know* I'd forget to mark every commit with [skip ci] or something. Now I need to modify a bunch of submodules

Re: GitLab forks and submodules

Depending on the patch, the ci feedback may be fundamental. Eg some of the native code gen hackery im doing impacts a whole bunch of configurations I can’t do locally. We could also have a wip/no-ci prefix ? Either way it’s certainlu true that we have finite resources and should endeavor to

Re: GitLab forks and submodules

I agree with Omer that we shouldn't encourage people to push wip branches to ghc/ghc. It wastes resources and pollutes the repo with lots of branches that will invariably not be deleted. I would rather we use absolute paths in the submodule file as I have spent far longer than I expected trying

Re: GitLab forks and submodules

You can specify `[skip ci]` in the commit message if you don't want to run the pipeline. When you are done, just amend your commit with the finalised note. Gabor On 1/8/19, Ömer Sinan Ağacan wrote: >> As I mention in the documentation, those with commits bits should feel >> free to push

Re: GitLab forks and submodules

> As I mention in the documentation, those with commits bits should feel > free to push branches to ghc/ghc. This is sometimes not ideal as it wastes GHC's CI resources. For example I make a lot of WIP commits to my work branches, and I don't want to keep CI machines busy for those. Ömer Ben

Re: GitLab forks and submodules

while making the case of contributing patches with submodule changes more difficult I don't understand this, can you give an example of what absolute paths make harder? Looking at the wiki pages and scripts we need to make relative paths work for everyone, I think it's clear that absolute

Re: GitLab forks and submodules

Moritz Angermann writes: > Can’t we have absolute submodule paths? Wouldn’t that elevate the > issue? > Perhaps; I mentioned this possibility in my earlier response. It's not clear which trade-off is better overall, however. > When we all had branches on ghc/ghc this > was not an issue. > As I

Re: GitLab forks and submodules

Can’t we have absolute submodule paths? Wouldn’t that elevate the issue? When we all had branches on ghc/ghc this was not an issue. Sent from my iPhone > On 8 Jan 2019, at 5:24 AM, Ben Gamari wrote: > > Simon Peyton Jones via ghc-devs writes: > >> Would it be worth describing this workflow

RE: GitLab forks and submodules

Simon Peyton Jones via ghc-devs writes: > Would it be worth describing this workflow explicitly in our "How to > use GitLab for GHC development" page? > Yes, indeed it would. I have asked David, who is currently looking at revising our contributor documentation, to do so. Cheers, - Ben

RE: GitLab forks and submodules

Would it be worth describing this workflow explicitly in our "How to use GitLab for GHC development" page? S | -Original Message- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 07 January 2019 15:33 | To: Moritz Angermann ; ghc-devs | Subject: Re: GitLab forks and

Re: GitLab forks and submodules

Moritz Angermann writes: > Hi *, > > so what do we do with submodules? If you point someone to a fork of ghc, say: > > gitlab.haskell.org/foo/ghc > Indeed submodules have been a constant thorn in our side. We encounter this same issue during CI jobs on forks. To work a

GitLab forks and submodules

Hi *, so what do we do with submodules? If you point someone to a fork of ghc, say: gitlab.haskell.org/foo/ghc and they try to check it out, they will run into issues because foo didn't clone all the submodules. So how is one supposed to clone a forked ghc repository? Cheers, Moritz

Re: GitLab CI for patches across submodules

Am Sa., 5. Jan. 2019 um 22:18 Uhr schrieb Ben Gamari : However, we can certainly use the upstream repo during CI builds. I have opened !78 which should hopefully fix this. Perhaps you could rebase on topp of this and check? > Thanks, Ben, that works for me. What I hadn't realized before, is

Re: GitLab CI for patches across submodules

Simon Jakobi via ghc-devs writes: > Hi, > > I just tried to use GitLab CI to validate a GHC patch including changes to > Haddock: https://gitlab.haskell.org/sjakobi/ghc/pipelines/842 > > The problem is that the CI script tries to find my Haddock commit at >

RE: submodules

Thanks Reid, Matthew. S | -Original Message- | From: Reid Barton [mailto:rwbar...@gmail.com] | Sent: 11 April 2017 17:01 | To: Simon Peyton Jones <simo...@microsoft.com> | Cc: ghc-devs <ghc-devs@haskell.org> | Subject: Re: submodules | | Hi Simon, | | This hap

Re: submodules

Hi Simon, This happens because the locations of the submodules are specified using relative paths from the main GHC repository, but Tritlo has only made a fork of the main GHC repo, not all the submodules. I would do this: * Clone from the main GHC repo (including submodules) however you usually

submodules

Devs I want to build a GHC from someone else repo; this one actually g...@github.com:Tritlo/ghc.git. But when I clone it, and then do git submodule init; git submodule update, I get lots of git submodule update Cloning into

Submodules on a branch

commit for libraries/unix than in my branch Question (sticking plaster): how can I say “Just make my sub-modules match HEAD please”? Question (cause): how can I ensure that I do update my branch to the submodule of HEAD when doing ‘git merge’? Getting submodules out of sync is very tiresome

Re: Submodules on a branch

://gist.github.com/bgamari/919e1279c1615b9b1cb4/raw/bbb1be6106b73f05d35eff256351187931d43ac3/checkout-submodules $ chmod ugo+rx checkout-submodules [ensure it's in $PATH] $ cd $path_to_ghc $ checkout-submodules master [a bit of output is produced] $ git commit -m "

Updating submodules

Herbert, or anyone, I'm very confused about the workflow for updating submodules. I want to update several (to remove redundant constraints from contexts) which are maintained by GHC HQ. But for libraries/parallel I find: * There is no .git/config in libraries/parallel. (Whereas

Re: Updating submodules

Hello Simon, On 2015-01-06 at 10:59:44 +0100, Simon Peyton Jones wrote: I'm very confused about the workflow for updating submodules. I want to update several (to remove redundant constraints from contexts) which are maintained by GHC HQ. But for libraries/parallel I find

RE: Updating submodules

| * There is no .git/config in libraries/parallel. (Whereas | there is for another submodule, libraries/hoopl.) | | * There is, however, a .git file which points to | .git/modules/libraries/parallel | | That's most likely because libraries/hoopl wasn't created via `git

RE: Updating submodules

Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: RE: Updating submodules | | | * There is no .git/config in libraries/parallel. | (Whereas | | there is for another submodule, libraries/hoopl.) | | | | * There is, however, a .git file which points to | | .git/modules

RE: Updating submodules

] Sent: 06 January 2015 16:28 To: Simon Peyton Jones; Herbert Valerio Riedel Cc: ghc-devs@haskell.org Subject: Re: Updating submodules Has everyone seen the git man page generator ;-)? Hilarious. http://git-man-page-generator.lokaltog.net/ On Tue Jan 06 2015 at 7:49:30 AM Simon Peyton Jones simo

Re: Updating submodules

On Tue, Jan 6, 2015 at 11:28 AM, Ryan Newton rrnew...@gmail.com wrote: Has everyone seen the git man page generator ;-)? Hilarious. http://git-man-page-generator.lokaltog.net/ I still want the git version of http://thedoomthatcametopuppet.tumblr.com/ :p -- brandon s allbery kf8nh

Re: Updating submodules

check/proof-read Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of | Simon Peyton Jones | Sent: 06 January 2015 10:49 | To: Herbert Valerio Riedel | Cc: ghc-devs@haskell.org | Subject: RE: Updating submodules

Re: phabricator issue with git submodules.

Karel, When your submodules get updated, you need to add them to your commit (since the parent repository maintains pointers to the submodules). Then they will no longer show up as dirty and you can submit the Phabricator patch. Edward Excerpts from Karel Gardas's message of 2014-07-25 22:48:21

Re: phabricator issue with git submodules.

it points to currently non-existing patches (in public libraries/unix + primitive). Am I right that this works in this way? Thanks, Karel On 07/26/14 09:39 PM, Edward Z. Yang wrote: Hello Karel, When your submodules get updated, you need to add them to your commit (since

Re: phabricator issue with git submodules.

Hello Karel, When your submodules get updated, you need to add them to your commit (since the parent repository maintains pointers to the submodules). Then they will no longer show up as dirty and you can submit the Phabricator patch. Edward Excerpts from Karel Gardas's message of 2014-07-25 22

Re: how to checkout proper submodules

are git submodules then sync-all can be replaced with something that helps out with git submodule branching, as it helps out with multi-repo branching now (a little bit). Best, -Ryan On Wed, Jun 5, 2013 at 2:02 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: I think that testsuite should

Re: how to checkout proper submodules

, and several others (integer-gmp/integer-simple, hpc, etc.) They don't need to be submodules and making them so is unnecessary complexity, when they can realistically never be used with anything else. This cuts down on something like 10 repositories, IIRC. 2) Several more should become submodules

RE: how to checkout proper submodules

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

Re: how to checkout proper submodules

that moving to all-submodules is better than the current mix. Still, one could argue that making an improvement is premature if (1) there is significant transition cost to make the change, or (2) it puts you on some kind of local optima that makes it harder to get to a higher peak. Yet in the case of all

Re: Multiple repositories, submodules, subtrees and whatnot (Was: Re: libffi)

Given the recent debate about using submodules or subtrees, and the occasional issues with sync-all: did anyone ever look into using the 'repo' tool? Created by Google for Android development (AFAIK), but also used by several other projects. See https://code.google.com/p/git-repo/ Con

Multiple repositories, submodules, subtrees and whatnot (Was: Re: libffi)

Given the recent debate about using submodules or subtrees, and the occasional issues with sync-all: did anyone ever look into using the 'repo' tool? Created by Google for Android development (AFAIK), but also used by several other projects. See https://code.google.com/p/git-repo/ Nicolas On Sat

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

On 09/06/13 17:51, Ian Lynagh wrote: On Sun, Jun 09, 2013 at 11:15:37AM -0500, Austin Seipp wrote: I'm referring to Joachim Breitner's work on splitting the base. So what's the timeline here? As soon as possible after 7.8 is branched. Has there been a decision somewhere on what to do?

Re: how to checkout proper submodules

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

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

On 06/12/2013 12:37 PM, Ian Lynagh wrote: On Wed, Jun 12, 2013 at 12:54:38AM +0200, Daniel Trstenjak wrote: I guess [the merge commits] may not cause any actual problems, but it's certainly nicer not having them (which is what using submodules gives us). Just to clarify, my problem isn't so

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

as a separate branch. So everything that applies to the merging of branches also applies to the merging by git-subtree. I didn't follow that. Here's an example of what happens with just a plain git repo, with no branches, submodules or subrepos involved: -8--8--8--8

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

Hi Ian, I guess they may not cause any actual problems, but it's certainly nicer not having them (which is what using submodules gives us). I don't quite understand how you should get rid of these merge commits by using submodules, because at the end every submodule is just a git repository

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

On Mon, Jun 10, 2013 at 1:32 PM, Roman Cheplyaka r...@ro-che.info wrote: * John Lato jwl...@gmail.com [2013-06-10 07:59:55+0800] On Mon, Jun 10, 2013 at 1:32 AM, Roman Cheplyaka r...@ro-che.info wrote: What I'm trying to say here is that there's hope for a portable base. Maybe not

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

On Mon, 2013-06-10 at 11:45 +0100, Ian Lynagh wrote: Side note: the fingerprint script *didn't even work* for almost a year after it was introduced; see commit 73ce2e70. Which implies that wanting to go back in time is rare, so making it easy should be given low weight when considering

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

On 06/10/2013 11:49 AM, Nicolas Trangez wrote: On Mon, 2013-06-10 at 11:45 +0100, Ian Lynagh wrote: Side note: the fingerprint script *didn't even work* for almost a year after it was introduced; see commit 73ce2e70. Which implies that wanting to go back in time is rare, so making it easy

Re: how to checkout proper submodules

are in this situation of half submodules, half random-floating-git-repository-checkouts? Submodules are very handy for libraries that someone else maintains: We can make a local change to the library when we need something fixed, and then, when upstream has a fix too, we can jump straight

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

Hi Austin, I apologize for not having read the full email yet (I'm in a hurry right now), but... * Austin Seipp ase...@pobox.com [2013-06-09 00:23:22-0500] -- Let's just put base and testsuite inside the GHC repository directly. No submodules, no floating repos. Just put it directly inside

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

Hi Roman, On Sun, Jun 9, 2013 at 1:44 AM, Roman Cheplyaka r...@ro-che.info wrote: I'm a strong -1 on this. As one example, we have forks of base and ghc-prim for Haskell suite: https://github.com/haskell-suite/base https://github.com/haskell-suite/ghc-prim which would be much more

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

to their strong interdependence.) But again, I'm totally OK with a lot of these other repositories being submodules. For example, process, unix, deepseq, filepath, directory. Those don't need to be folded in. Lots of them could have their own maintainers with separate upstreams. They're touched

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

On Sun, Jun 09, 2013 at 11:15:37AM -0500, Austin Seipp wrote: I'm referring to Joachim Breitner's work on splitting the base. So what's the timeline here? As soon as possible after 7.8 is branched. Thanks Ian ___ ghc-devs mailing list

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

. But the high-traffic repositories (base, testsuite) are already submodules, right? For me the major problem of the current setup is that we cannot use one of the most important features of a VCS, i.e. going back in time. The only solutions to this problem that I am aware of are folding

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

Oh, and I've been made aware that git 1.7 and later can checkout a subdirectory of a repo - this partially invalidates my previous argument. I'm saying partially, because it is a bit more difficult than dealing with a library that has its own repo + it seems that some potential contributors

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

* Austin Seipp ase...@pobox.com [2013-06-09 11:15:37-0500] Hi Roman, On Sun, Jun 9, 2013 at 1:44 AM, Roman Cheplyaka r...@ro-che.info wrote: I'm a strong -1 on this. As one example, we have forks of base and ghc-prim for Haskell suite: https://github.com/haskell-suite/base

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

On Mon, Jun 10, 2013 at 1:32 AM, Roman Cheplyaka r...@ro-che.info wrote: What I'm trying to say here is that there's hope for a portable base. Maybe not in the form of split base — I don't know. But it's the direction we should be moving anyways. And usurping base by GHC is a move in the

Re: Proposal: better library management ideas (was: how to checkout proper submodules)

* John Lato jwl...@gmail.com [2013-06-10 07:59:55+0800] On Mon, Jun 10, 2013 at 1:32 AM, Roman Cheplyaka r...@ro-che.info wrote: What I'm trying to say here is that there's hope for a portable base. Maybe not in the form of split base — I don't know. But it's the direction we should be

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

RE: how to checkout proper submodules

| 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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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 tree would be a serious benefit IMO

Re: how to checkout proper submodules

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/

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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 GitHub

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

of these are pretty important in a lot of ways. It's not clear what the movement-strategy here is and it is definitely not going to be free, or painless.) This is definitely a more touchy issue, but I can see both sides. 3) Regarding Daniel Trstenjak's complaint: submodules from a workflow perspective may suck

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

? submodules are fine for tracking repositories, but if you're all the time changing multiple submodules, than it's a sign that you've a strong dependency between the repositories, so why not just having one repository? 2) One thing this *does* complicate is that currently, some repositories

Re: how to checkout proper submodules

don't intend to wage at the moment. submodules are fine for tracking repositories, but if you're all the time changing multiple submodules, than it's a sign that you've a strong dependency between the repositories, so why not just having one repository? I would agree. In practice many

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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:

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

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

Re: how to checkout proper submodules

-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

Re: how to checkout proper submodules

rather unsatisfying. - Answer over, rant begins. - 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

Re: how to checkout proper submodules

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

Re: Stuck again on submodules

Does this help: git submodule update libraries/Cabal/ ? Janek Dnia czwartek, 9 maja 2013, Simon Peyton-Jones napisał: Help! I can't build ghc! I get this utils/ghc-pkg/Main.hs:1160:24: Not in scope: `showSimpleInstalledPackageInfoField' Perhaps you meant

Re: Stuck again on submodules

: Simon Peyton-Jones | Subject: Re: Stuck again on submodules | | Does this help: | | git submodule update libraries/Cabal/ | | ? | | Janek | | | | Dnia czwartek, 9 maja 2013, Simon Peyton-Jones napisał: | Help! I can't build ghc! | | I get this | utils/ghc-pkg/Main.hs:1160:24

RE: Stuck again on submodules

Update Cabal | -Original Message- | From: Ian Lynagh [mailto:i...@well-typed.com] | Sent: 09 May 2013 13:40 | To: Simon Peyton-Jones | Cc: ghc-devs@haskell.org | Subject: Re: Stuck again on submodules | | | Hi Simon, | | On Thu, May 09, 2013 at 12:31:22PM +, Simon Peyton-Jones wrote

RE: Stuck again on submodules

no, I'm on master From: Patrick Palka [mailto:patr...@parcs.ath.cx] Sent: 09 May 2013 13:42 To: Simon Peyton-Jones Cc: Jan Stolarek; ghc-devs@haskell.org Subject: Re: Stuck again on submodules Are you by any chance on a non-'master' branch of GHC? This happened to me when I ran `./sync-all pull

Re: Stuck again on submodules

On Thu, May 09, 2013 at 12:44:45PM +, Simon Peyton-Jones wrote: aha, good catch. It looks as if my commit for cardinality analysis somehow jiggered the Cabal tree. I have no idea how or why. How can I undo that? I think this will do it: cd libraries/Cabal git reset --hard