Reputation: 133
I've checked several answers, but none seem to hit what I am looking at (or otherwise don't quite make sense to me).
I am working on a project that follows, say, the Wordpress model of:
root/
root/core/
root/core/stuff
root/plugins
root/plugins/1
root/plugins/2
The entire core is a repo, and plugins 1, 2, etc... are all separate repos by many different contributors.
Submodules seems to be complixifying the issue - when all I want is to be able to
A) make changes / push / pull core
and
B) make changes / push / pull plugin(s)
in no linked manner (eg, I don't give a flip what state the plugin is in when I make a commit to the core. I would just rather assume the plugins don't exist while working on core.)
Wouldn't simply using .gitignore to ignore the entire /plugins/ directory be the most straight-forward?
Similar questions:
Use gitignore to nest repositories.
Do you ignore a git submodule in your .gitignore or commit it to your repo?
Upvotes: 4
Views: 727
Reputation: 815
I found a pretty good use case for using .gitignore instead of learning submodules.
I have a rails app that consists of rails engines. The only catch is the way I have my generators set up, the engines need to exist within the file structure of the rails app. It gets pretty messy if your rails engine and your rails app are under different repos because when an engine changes you have to commit both the engine and app.
To get around this I gitignored the engines folder and in my gemfile I set it to use the remote copy of the engine on github. That way there are no dependencies that I'm missing if I clone it down later. If I want to see the local changes immediately in the main app I switch the gemfile to use the local version of the engine but switch it back before I commit.
To better answer your question, I think using .gitignore is fine if you can specify in the dependencies of your app to use the remote copy instead of the gitignored local copy.
Upvotes: 0
Reputation: 1323973
The idea of submodules is allowing the parent repo (the root
folder in your case) to record the exact version of the sub-repos you are using when committing something in said parent repo.
That will allow you to clone the repo knowing that you will get compatible version of the sub-repos, working with your current set of files.
I don't give a flip what state the plugin is in when I make a commit to the core. I would just rather assume the plugins don't exist while working on core
You can do that without problem with submodules.
The only additional step, when committing and pushing core
, is to go back in the parent repo, commit and push as well there (in order to record the new core
SHA1).
More on that process on "True nature of submodules".
Upvotes: 4