Proposal: better library management ideas (was: how to checkout proper submodules)
roma at ro-che.info
Mon Jun 10 12:32:17 CEST 2013
Hmm, okay, if you're saying that this workflow works and is not very
painful, then I withdraw my objection.
* 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.
More information about the ghc-devs