It would be great to be able to define which dependency to use as submodule and which not.
For example, we have a project with some third party framework dependencies that we want to fetch directly in our local git to avoid problem if the project disappear but we also have some internal framework that we want to add as submodule to ease their modification while developing the main project.
so we could have something like that in the Cartfile:
git "git@myinternal_project.git" "master" --use-submodule
github "ThirdParty/GreatFramework" ~> 1.0 --no-submodule
syntax leaved to your discretion ;)
This is a slightly different idea than #177
Adding my support for some capability like this. When mirror repos on enterprise githubs ... a .gitmodule reference can be problematic because CarthageKit/Git.swift enforces git submodule update --init --recursive. The submodules will often times point to a github.com repo.
This.
My preference is to check in all the sources for the app I'm working on, just in case "things" would prevent me from reproducing an old build/branch.
So I'll probably use --no-build --no-use-binaries and check in my Carthage/Checkouts directory.
But if I'm working on a module, or co-developing one of my own modules, I might want just that one to be a submodule while I'm developing, and then check out normally before the pull request goes in.
It'd be really handy for Carthage to be able to gracefully transition between a submodule checkout and a bare checkout, both ways.
In my Carthage experiments, I tried removing a submodule from the command line, and it's a bit tricky. I found this stackoverflow answer that seems to know all the pieces of Git that have to be touched up when doing that.
P.S. I really appreciate the way Carthage will do the important stuff (finding dependencies) and is willing to be out of the way for the parts that are less central to the task (--no-build, --no-use-binaries, letting me set up my own .xcworkspace, submodules). Thanks for a really neat tool that makes it easy.
P.P.S: Your code is really well-organized, I can tell what's going on in there. I'm not always long on spare time (also kind of new to Swift, and very curious about Reactive stuff), but I think I could actually make a patch!
I echo this request
I agree. My project uses some in-house frameworks I'd like to include as submodules so I can do development on them alongside my main project, but other dependencies we pull from github I don't want to be submodules. Surely this is not an uncommon use case.
+1
+1
+1
+1
Most helpful comment
+1