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

[Roman Cheplyaka]

Hmm, okay, if you're saying that this workflow works and is not very
painful, then I withdraw my objection.

Thanks,
Roman

* Daniel Trstenjak <daniel.trstenjak at gmail.com> [2013-06-10 12:06:56+0200]
> 
> 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.
> 
> 
> Greetings,
> Daniel