Re: organizing multiple repositories with dependencies
- From
- Hilco Wijbenga <hilco.wijbenga@gmail.com>
- Date
- Apr 17, 2012, 22:49 UTC
- Message-ID
- <CAE1pOi2FQtyahcJUJ+CZRLLYN7vxGaOmUiBJ-_AfC-T-ZEY_Sg@mail.gmail.com>
- In-Reply-To
- <CAJsNXTmfRZvpO=ooB8yKUqGqbU4g5A78=dzt2vPPrs1q+J4ZrA@mail.gmail.com>
On 17 April 2012 15:25, PJ Weisberg <pj@irregularexpressions.net> wrote:
Show 14 quoted lines
> On Tue, Apr 17, 2012 at 2:43 PM, Hilco Wijbenga > <hilco.wijbenga@gmail.com> wrote: > >> I'm assuming that if you have subproject S in umbrella project U and a >> branch "topic" in U then that same branch should exist in S. Any >> changes in S's topic should show up in U's topic (probably after some >> sort of update command like git fetch/pull). This should be unusual, >> though, you should be working in U, not S. If you want to work on >> something in S that you don't want to see in U, then you should not be >> working in S's topic. > > This paragraph makes me wonder why you want to use submodules at all. > Wouldn't a sparse checkout be a better fit for what you're trying to > accomplish?
No, I don't think so but I could be wrong. I want to be able to easily build and release the individual projects separately (manually and on the build server). I believe that with a sparse checkout I still get the entire directory tree. This just doesn't work well. I can make it work but then I lose other nice features (unrelated to Git).
Basically, I want things separate for release management but together for development.