how to checkout proper submodules

[Austin Seipp]

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 repository from my
understanding, in practice all developers will probably need to touch
multiple repositories for several reasons anyway (like testsuite and
base.) That means the third-party merge is pretty much always going to
happen for any non-sizeable work, the person who *did* the work will
be the one doing it, essentially amounting to basically everyone
needing subtree in the long term.

I may be wrong about this. If I am please call me out on it. And there
may be alternative workflows for patch-submitters to help this. But in
general, I'd rather not have to tell GHC developers they probably need
a special git build in the long haul.

2) I agree with John Lato. I think the immediate problem of fixing the
submodule situation is a core issue, and GitHub can come later. Or at
the very least, we should discuss GitHub in its own email thread.
That's because while I see the problem of "our current setup is bad"
as rather obvious and with a clear mitigation/fix, there *are* some
legitimate complaints about GitHub that won't be resolved so easily.
We should tackle each separately (remember: we have thousands of
existing tickets, wiki pages, historical existing links, etc. All 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 a little, but realistically we use their *exact*
workflow anyway as it stands. We just don't get any of the benefits:
in practice developers will make branches in each affected repo and
push them and maintain them concurrently. Eventually they will be
merged into master for each respective repository. This process will
not change if we move entirely to submodules as you said.

Some extra food for thought:

1) We could now delete ./sync-all if this happened. It's almost 1000
lines of code dedicated to managing this stuff. Instead, we merely
tell all hackers to clone with 'git clone --init --recursive' and
viola! After a git clone, you can immediately start building. That'd
be great.

2) One thing this *does* complicate is that currently, some
repositories are optional. Submodules effectively make them 100%
non-optional. Now, normally, I would say all developers should have
every relevant library anyway. In this case however, it is a tad bit
annoying. On my ARM machines for example, DPH regularly fails
late-in-build due to a bug in the (custom) linker, because dph
requires stage2+ghci. But it also takes a long time to build DPH, so
in practice I just remove it to save myself that time. Some others do
the same.

That said, I'm potentially the vast minority here, and I'd be willing
to just deal with it in the mean time if we can do this (this is the
*exception* and certainly not the rule.) Not that big a deal, and it
can also be fixed later.

There are probably other things that I can't think of, but I'm sure
you can all think of other stuff too. :)

On Wed, Jun 5, 2013 at 8:49 AM, Daniel Trstenjak
<daniel.trstenjak at gmail.com> 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 to develop some kind of feature which involves
> changes on multiple repositories/submodules and you would like to
> do it in a branch, than you have to create a branch in each repository,
> commit separately in each repository and than merge back each repository
> into its master branch.
>
>
> Greetings,
> Daniel
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs



-- 
Regards,
Austin - PGP: 4096R/0x91384671