Extract into two repos?
dhc02 opened this issue · 6 comments
Just an idea: the submodule thing (and maintaining the codebase in general) becomes less awkward if you're calling a separate repo as a submodule rather than a different branch of the same repo.
So how about two modular things able to be contributed to separately: a front end (currently gh-pages) and a back end (currently master)?
I'm really not sure what the best approach is, but I like that this is being discussed.
Are there any examples of how other people are doing it?
I'm going to try forking, making a change and then applying it back onto the main repo and see what the process is like.
Ok i've tested this and submitting a pull-request on the master branch is problematic.
I think I'm just going to merge everything into gh-pages branch and then use that one as master.
So I admittedly haven't had time to peruse the code yet, but I think there's real potential in separating this into two apps, essentially:
A: a client-facing app that displays different information sets overlaid on an interactive keyboard, and
B: an API-only app that organizes and provides the information used by app A via API calls
Down this path also lies the possibility of allowing app B to accept new and updated keyboard schemas through some sort of public-facing interface rather than having them be part of the core codebase.
I'll dive in tomorrow and take a look.
Currently the exporters know exactly where to export their data to, given the standardized layout of the repo with the submodule.
I worry that by splitting it up into multiple repo's, it's going to be:
- needlessly complicated for people who want to contribute small quick changes (one line changes that fix shortcuts that were incorrectly mapped, for example)
- hard to enforce a standardized layout (where do the exporters export to?)
- pull-requests with changes in both the exporters and the site are split up
I've created a gh-pages-reorg branch with everything merged into one like I mentioned previously. I'm going to do some tests with forking that and see if it's acceptable.
Check it out here:
https://github.com/waldobronchart/ShortcutMapper/tree/gh-pages-reorg
Ok so I've done this now. The repo has one main branch called gh-pages where everything lives.
For reasons I mentioned earlier, I think this is the least confusing option.
I appreciate your input very much :)
I'll add that it can always be changed later on - nothing is set in stone.