Feature/configuration file

[mdsimpson42]

WIP - Currently Untested The latest version of the code from colouring-london/colouring-core, with additional documentation on the config files.

[matkoniecz]

maybe it would be better to preserve history? Rather than collapse it in a https://github.com/colouring-cities/colouring-core/pull/5/commits/2e784ce69fe02528aa2854f7fbc81812259f7b88 commit?

Basically, I would setup this repository as copy of colouring London repository as this allows to avoid loss of history, commits and so on. I look often at commits made to files as it allows to understand why some changes were made and who can be consulted about design decision that were made, look at related issues and so on.

[matkoniecz]

Maybe it would be a good idea to migrate colouring-london repository to colouring-cities repository, migrate London specific content into config file?

[tomalrussell]

Beyond the first commit, changes in this PR are all docs and fixing some links/references, look good 👍

Agreed with @matkoniecz that we should preserve history. Two options:

1. push the full history to this repository
2. delete this repository temporarily and rename colouring london in its place

I think I prefer 2 - keeps the record of code next to history of issues and PRs; is less of a fresh start but means the focus moves clearly to the “core”. Assumes we’re confident in the configuration code and avoids working on a(nother) fork for an extended period.

[matkoniecz]

Yes, preserving issue/PR numbers is quite helpful so (2) also seems preferable to me.

It has some negatives, but as project gets larger ability to look at file history/past commits/git blame/git bisect etc is more and more useful. And often following to related issues/PR is the final step.

[mdsimpson42]

Yeah, to be honest, I've been struggling to get my head around this.

Ultimately, we want this to be the base repository and for Colouring London (and all other "Colouring..." projects) to spin off from it. So are we saying it's better to delete this repo, then rename "Colouring London" to "Colouring Core", and then create a new "Colouring London" repo as a Fork from it?

I'm assuming Forking is the best way to do it? I haven't worked on a project with this many different versions/repos before. How easy is it to fold changes from the forked "Colouring London" back into the Core repo? How will this affect all of the other projects that are currently forked from Colouring London?

I just want to make sure I do it right and don't mess it up for everyone before I press "go"!

[matkoniecz]

So are we saying it's better to delete this repo, then rename "Colouring London" to "Colouring Core", and then create a new "Colouring London" repo as a Fork from it?

Yes, though I would also migrate issues and wiki (and maybe something else).

Maybe rename to colouring-cities/archive-colouring-core-first-attempt and archive rather than deleting to keep for example this discussion.

How will this affect all of the other projects that are currently forked from Colouring London?

Rename and creation a new repository under old name may result in some links, including remotes in git repositories to end in weird state. But as new repo will be fork of previous one and still contain the same commits it should not be a problem, right?

I'm assuming Forking is the best way to do it? I haven't worked on a project with this many different versions/repos before. How easy is it to fold changes from the forked "Colouring London" back into the Core repo?

This can be done with multiple remotes and merging/cherry picking. It is easy in CLI git and should be easy in decent git GUIs.

Though I expect that changes usable in Colouring Core would be made against Core repository, and Colouring London would merge upstream.

---

A bit different situation, but I do something similar in https://github.com/matkoniecz/Zazolc/commits/fork

There is https://github.com/streetcomplete/StreetComplete which is the main repository, and https://github.com/matkoniecz/Zazolc which is a fork that continues to merge in upstream.

In my local repository I added https://github.com/matkoniecz/Zazolc as origin and added https://github.com/streetcomplete/StreetComplete as upstream

I have branch master which is exactly the same as upstream/master and is regularly updated.

I have branch fork with my changes and master is from time to time merged into fork.

I contribute to https://github.com/streetcomplete/StreetComplete changes benefiting entire project. Fork gets commits with my own changes which for various reasons are ineligible for main version.

So scenario with work on fork that uses all options would have something like

git checkout fork
git commit -m "my changes"
git merge my_local_branch
git checkout master
git fetch upstream
git reset --hard upstream/master
git checkout fork
git merge master

this will commit some local changes, merge local brach and merge in new commits upstream

Typical one would be just regular git commit -m "my changes" or git merge my_local_branch - above is showing all possibilities, regular activity does not involve all of that.

If I would be adding something upstream - committing would be like normal.

[tomalrussell]

delete this repo, then rename "Colouring London" to "Colouring Core"

Yes, I think this is the thing to do. (Edit: as someone said above, actually rename this repo instead of deleting)

I think the situation described with multiple remotes, merging from upstream, is a reasonable solution only if we continue to need different code for each platform, and it might be a good first next step..

..but we should be aiming for a “Colouring core application” that can be deployed and configured, so for example the only reason to keep a “Colouring London” repository is to keep the configuration in version control - deployment is then something like:

• pull/push to update Colouring London config
• run some command to pull a tagged version of the core application
• run the application (or set of services)

[matkoniecz]

Yes, that would be even better - though not immediately available.

[traveller195]

hello ;-) nice discussion and interesting aspects. I prefer also to keep the history of the repo.

Question: I was also wondering, what could be the best way of updating e.g. Colouring Dresden repo from Colouring Core ? perhaps, syncing the fork (like it es shown here: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork ) could be the best way of the perspective of repo Colouring Dresden?

so, after important changes in Colouring Core, I can start the syncing manually?

do you have also other suggestions? best

[mdsimpson42]

Hi @traveller195. Yes, I think that's the best way to do it, and I believe it's how the other projects are set up, but I haven't worked a lot with forked projects before.

[mdsimpson42]

I'm going to begin the process of renaming everything now, starting with this repo. I'll just leave this pull request as it is for now.