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

[Geoffrey Mainland]

On 06/10/2013 11:06 AM, Daniel Trstenjak wrote:
> On Mon, Jun 10, 2013 at 10:54:06AM +0300, Roman Cheplyaka wrote:
>> My motivation for having a separate repository is that I can check it
>> out and work on it without having to check out the whole GHC.
>
> With git-subtree you can have both. A separate repository for easy
> forking of e.g. base and just one repository for GHC with a sub directory
> for base.
>
> At work we're sharing a quite big library between two development teams.
> There's a separate repository for this library, which is used for
> synchronization between both projects. Each project has it's own
> repository with a sub directory containing the library and git-subtree
> is used to merge this sub directory with the library repository.
>
> Most developers don't even have to care that there's a separate
> repository for the library, they're just working with the one project
repository.
>
> From time to time - perhaps once a week - the changes in the projects
> get merged back into the library repository.
>
> git-submodules is a burden for every developer, git-subtree is "just" a
> burden for the developer doing the merges with the external repository.
>
> The git-subtree script is more or less just a nice wrapper around the
> subtree merge strategy of git-merge. It uses only the available git
commands.

I mentioned git-subtree as a possible alternative earlier in the
thread. One of the primary objections at the time was that the subtree
command is not installed by default in, e.g., the Ubuntu git package.

Merging base and/or testsuite into the ghc repository wouldn't solve the
primary issue, which is that we can't reproduce a full source code tree
without to resorting to the fingerprints script, and even then we can't
bisect. Side note: the fingerprint script *didn't even work* for almost
a year after it was introduced; see commit 73ce2e70.

I think there are three realistic choices about how we should resolve
this issue. Our choice affects the decision about whether or not base
and/or testsuite should be merged into the ghc repository, so I think
the merger discussion should be tabled for the time being.

1) Leave everything as-is. We live with a mix of submodules and
fingerprints.

2) Use submodules.

3) Use subtrees.

I don't think there is a realistic third option, e.g., use a mix of
subtrees and submodules, but I may be wrong.

So, if we can agree that these are the three realistic alternatives, I
volunteer to flesh out the wiki so it lists the pros and cons of each
choice. If there are other sane paths forward besides these three,
please let us know!

Geoff