Timeline for Private and Public version of repository with minor difference
Current License: CC BY-SA 4.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 15, 2019 at 9:05 | comment | added | Pete | @BryceKille I'm not sure I understand you. If you have a piece of functionality that is currently only in the "private" system and you want to make it available in both, then you would remove it from "private" and add it to "shared". You wouldn't need to change "public" at all (with the possible exception of some glue code to make it show up in the user interface). | |
| Nov 14, 2019 at 23:45 | comment | added | Throckmorton | Yes that is how I understood it. However, my point is if we want to add any private functionality to a module in the “shared” repo, we would have to remove it from the repo entirely and copy it to the two other repos | |
| Nov 14, 2019 at 9:43 | comment | added | Pete | @BryceKille Fair enough on your first two points, however for the third, I think you've misunderstood slightly. Anything that's only used by the private version would stay in your existing private repo. The shared repo is only for things that are in both public AND private. | |
| Nov 13, 2019 at 19:40 | comment | added | Christophe | @BryceKille ok, but if you would have the common base as explained here, and have the two others as a sync fork ? (help.github.com/en/github/…) | |
| Nov 13, 2019 at 17:59 | comment | added | Throckmorton | While this would remove the presence of some redundant code, I think it would add overhead for the users to install, as well as causing some users to potentially report bugs/feature requests on the wrong repository. It also wouldnt be robust to changes to the shared repo that only should be used by the private version. There are definitely advantages to this, but it's probably not worth transitioning both codebases to an entirely new structure. | |
| Nov 13, 2019 at 17:53 | history | answered | Pete | CC BY-SA 4.0 |