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.trsten...@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
