4 ms·

While mid-reply and defining what the problem is, I realized a solution would be to just ignore the nested git project B, and deal with them separately. I must

While mid-reply and defining what the problem is, I realized a solution would be to just ignore the nested git project B, and deal with them separately. I must admit my original question wasn't well thought out, as I can't recall why it was important that there be a relationship between A and B at all, even if they are of the same project. Mid-reply context preserved below. ---- I have a git-inited folder A, called 'Build my web app'. Inside it, it has non-source-code stuff like pictures, pdfs, notes. Also inside it is a folder B, called 'my-web-app-js', which is source code. [Problem was that making a commit in project B would trigger unexpected changes in A]

PeterWhittaker 6y ago
The non-source code stuff can be ignored via .gitignore (more on that in a moment), assuming you do not want it in the repo at all. Your 'B' use case sounds like one we have right now: A framework, if you will ('A') and apps delivered via that framework ('B', 'C', etc.). Eventually, we will deliver A as a package and the apps as plug-ins to that package (more or less) but right now they all live together (npm run start in A brings in the apps in B, C, etc.). Our top-level folder has a .gitignore that looks like this: * !thisProjectFile.js !that.css !images/\* !otherArtefacts/\* where the items preceded by ! are all in the A repo, things we want git to consider when in A but not in B, C, etc. In A's top-level folder, do a git clone of the repos for B, C, etc., and their folders will be created in that folder, but 1. All git operations in A will ignore B, C, etc., because of the .gitignore, and 2. Operations in B, C, etc., will ignore A, because it is "outside" Works well enough for now.