4

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?

What is the advantage of using git submodules over having a repo inside another repo with a gitignore?

Community
  • 1
  • 1
Alltheprettyhorses
  • 113
  • 1
  • 2
  • 9

2 Answers2

4

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".

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    I guess until I do figure out sub-modules (and the intricacies) is there anything particularly _wrong_ or _dangerous_ with using .gitignore and treating each plugin repo separately? Cause it sure seems _simpler_ – Alltheprettyhorses May 02 '13 at 09:31
  • @Alltheprettyhorses yes: when cloning your main repo later, you have no idea if the latest version of the sub-repos will still work with said main repo. Submodules are there to allow you to record a *configuration* (i.e. the exact list of SHA1 you need for your project to work). – VonC May 02 '13 at 09:33
  • Ahh - so 'caveat emptor.' But really, since I'm going from a "no git, download code and install after each update, and when things break, put out the fires" type system -- its what I'm used to... – Alltheprettyhorses May 02 '13 at 09:42
  • @Alltheprettyhorses it doesn't matter though, since git1.8.2 your submodules can be set to track the latest from a given sub-repo (instead of a fixed SHA1). I would still avoid the `.gitignore` solution, as it leaves no clue to another user cloning your repo that you are supposed to have those specific submodules (or even yourself, when cloning the repo some months later). – VonC May 02 '13 at 09:44
0

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.

CleoR
  • 806
  • 6
  • 18