Hmm, okay, if you're saying that this workflow works and is not very
painful, then I withdraw my objection.
Thanks,
Roman
* Daniel Trstenjak
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