how to checkout proper submodules

[Geoffrey Mainland]

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 <simonpj at 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-bounces at haskell.org
[mailto:ghc-devs-bounces at haskell.org]
>> | On Behalf Of Austin Seipp
>> | Sent: 05 June 2013 07:35
>> | To: Johan Tibell
>> | Cc: ghc-devs at 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.tibell at 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