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 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 and use forks and pull requests like the rest of the world? > (Using Git, but not GitHub's superb infrastructure, seems like a > terrible waste to me.) > > Simon Peyton-Jones <simo...@microsoft.com>: >> 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, provided I am told >> clearly in words of one syllable. >> >> I *very strongly* want to reduce barriers to entry for would-be >> contributors, and this is clearly a barrier we could lower. Making >> Kazu, Austin, Johan, etc more productive is massively valuable. >> >> There may be some history to how we arrived at this point, but that >> should not constrain for the future. We can change our workflow. I >> would want Ian and Simon to be thoroughly on board, but I regard the >> current setup as totally open to improvement. Please! >> >> BTW, Ian has written it up quite carefully here: >> http://hackage.haskell.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 Seipp >> | Sent: 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 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 impact-on-contributors cuts both ways. GHC has >> | an extremely small team of hackers as it stands, and we are lucky to >> | have *amazing* contributors like Kazu, Andreas, yourself, Simon & >> | Simon, and numerous others help make GHC what it is. Much of this is >> | volunteer work. But as the Haskell community grows, and we are at a >> | loss of other full-time contributors like Simon Marlow, I think we are >> | beginning to see the strain on GHC and its current contributors. So, >> | it's important to evaluate what we're doing right and wrong. This >> | feedback loop is always present even if seasoned contributors can live >> | with it - but new contributors will definitely be impacted. >> | >> | In this instance, I honestly find it disheartening that the answer to >> | things like "getting older revisions of the source code in HEAD," or >> | techniques like bisection is basically "that doesn't work." The second >> | is unfortunate, but the latter is pretty legitimately worrying. It >> | would be one thing if this was a one-off occurrence of some odd >> | developer-workflow. But I have answered the fundamental question here >> | (submodules vs free-floating clones) a handful of times myself at >> | least, experienced the pain of the decision myself when doing >> | rollbacks, and I'm sure other contributors can say the same. >> | >> | GHC is already a large, industry-strength software project with years >> | of work put behind it. The barrier to entry and contribution is not >> | exactly small, but I think we've all done a good job. I'd love to see >> | more people contributing. But I cannot help but find these discussions >> | a bit sad, where contributors are impaired due to regular/traditional >> | development workflows like rollbacks are rendered useless - due to >> | some odd source control discrepancy that nobody else on the planet >> | seems to suffer from. >> | >> | I guess the short version is basically that that you're absolutely >> | right: the time of Simon, Ian, and other high-profile contributors is >> | *extremely* important. But I'd also rather not have people like Kazu >> | potentially spend hours or even days doing what simple automation can >> | achieve in what is literally a few keystrokes, and not only that - par >> | for the course for other projects. This ultimately impacts the >> | development cycles of *everybody*. And even if Kazu deals with it - >> | what about the next person? >> | >> | On Wed, Jun 5, 2013 at 12:12 AM, Johan Tibell <johan.tib...@gmail.com> >> | wrote: >> | > The latest git release has improved submodules support some so if we now >> | > thing the benefits of submodules outweigh the costs we can discuss if we >> | > want to change to policy. I don't want to make that decision for other GHC >> | > developers that spend much more time on GHC than I (e.g. SPJ). Their >> | > productivity is more important than any inconveniences the lack of >> | > consistent use of submodules might cause me. >> | >> | >> | -- >> | Regards, >> | Austin - PGP: 4096R/0x91384671 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs