You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Right now, there is no immediate solution for adding cookietemple to an existing repo.
This would be a great feature since it keeps the history while solving the problems that arise with manually renaming and merging branches from a different origin.
I have provided my tutorial for doing this manually below, which hopefully helps in finding an automated solution in the future.
Describe the solution you would like
Best would be to run cookietemple sync in an existing repo which automatically detects that there is no TEMPLATE branch yet.
Alternatively, sth. like cookietemple create --existing-repo or so which would be executed within the folder of the existing repo.
The only real problem is associated with merge conflicts in the dockerfile, poetry.lock and pyproject.toml based on my experience.
But if these files exist, one could simply tell cookietemple to use the ones that already exist or add the cookietemple dev-dependencies in the pyproject.toml and call poetry install to update the poetry.lock file.
Additional context
Migrating an existing repo with a new cookietemple repo and keeping the history can be done this way (python only):
If you want to migrate, don't forget that cookietemple requires a new repository. If you want to keep the name, you need to first rename the existing repo.
In a first step, try to merge as many branches as possible, as it is much easier if you only need to merge one single branch. If you cannot do that, you will need to migrate each branch individually.
Create a new repository on github using cookietemple CLI
Clone the newly create repository locally, then add a second origin (the existing repo to be migrated) using git remote add <origin name> <URL>. Note: <origin name> must not be "origin", as this key already exists in the .git/config file. Choose for example "origin_existing_repo"; <URL> is either the https or ssh address of your existing repo.
git fetch --all in order to fetch all the branches from both origins. Then git checkout origin/development (this is the github development branch created by cookietemple).
Now, git merge <origin name>/<your main branch in the existing repo> --allow-unrelated-histories. You will need the additional flag, since the entire history of your main branch will be prepended to the single commit on the origin/development branch created by cookietemple.
You are likely getting merge conflicts, especially if you already have a Dockerfile, unit tests or a pyproject.toml + poetry.lock file. My personal advice: Overwrite the default Dockerfile with your Dockerfile, delete the poetry.lock and merge the pyproject.toml which mainly adds the cookietemple dev dependencies, then recreate the poetry.lock file by poetry install. This is the most critical point in the process. You should know how to use a mergetool, such as vimdiff, which you can configure using git config merge.tool vimdiff. Here, some cookietemple automation could help the average user immensely imo.
Now that your main branch is migrated, you can push the origin/development branch and it will contain the cookietemple template as well as your work and commit history.
If necessary, git checkout origin main and git merge origin/development.
Important notes:
If you have any other branches to merge, you can always git checkout development and git merge <origin name>/<your arbitrary branch in the exsiting repo>. Be aware, that your branches do not yet contain the cookietemple templates. It is therefore an option to first git checkout <your arbitrary branch in the existing repo> and then git merge origin/development. This also ensures you fix potential merge conflicts on your existing branch prior to merging it on the new development branch.
If you follow these instructions, you won't experience any merge conflicts other than the ones mentioned in point 6. Since the history of your main branch in the existing repo is now part of your development branch in the newly created cookietemple repo, you can now start checking out new branches from it without any issues and also merge branches from the existing repo without further problems, as long as they have been checked out from the main branch you used for migration in point 5.
Be aware of merge conflicts when fixing pre-commit hooks on the development branch before merging the other branches you might have in the existing repo . Since the automatic pipelines might do a lot of changes to your code, fixing these later on will be a nightmare. It is therefore recommended to first merge everything into origin/development, then freeze the repo (i.e. tell your collabs they should prepare to feel a Hinkelstein fall on their head if they dare to push / checkout new stuff during that time) until you have fixed all the github actions that fail before you release the repository for further development.
Afterwards, everyone is required to fixing the actions before merging onto development which ensures that you don't need to worry about merge conflicts that exceed the complexity of the occasional conflicts in the future. This is only true of course if everybody does pip install pre-commit and pre-commit install on their local machine or at least use nox manually before pushing new stuff (which should be the default anyways imo.)
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Right now, there is no immediate solution for adding cookietemple to an existing repo.
This would be a great feature since it keeps the history while solving the problems that arise with manually renaming and merging branches from a different origin.
I have provided my tutorial for doing this manually below, which hopefully helps in finding an automated solution in the future.
Describe the solution you would like
Best would be to run
cookietemple sync
in an existing repo which automatically detects that there is no TEMPLATE branch yet.Alternatively, sth. like
cookietemple create --existing-repo
or so which would be executed within the folder of the existing repo.The only real problem is associated with merge conflicts in the dockerfile, poetry.lock and pyproject.toml based on my experience.
But if these files exist, one could simply tell cookietemple to use the ones that already exist or add the cookietemple dev-dependencies in the pyproject.toml and call
poetry install
to update the poetry.lock file.Additional context
Migrating an existing repo with a new cookietemple repo and keeping the history can be done this way (python only):
If you want to migrate, don't forget that cookietemple requires a new repository. If you want to keep the name, you need to first rename the existing repo.
git remote add <origin name> <URL>
. Note:<origin name>
must not be "origin", as this key already exists in the.git/config
file. Choose for example "origin_existing_repo";<URL>
is either the https or ssh address of your existing repo.git fetch --all
in order to fetch all the branches from both origins. Thengit checkout origin/development
(this is the github development branch created by cookietemple).git merge <origin name>/<your main branch in the existing repo> --allow-unrelated-histories
. You will need the additional flag, since the entire history of your main branch will be prepended to the single commit on theorigin/development
branch created by cookietemple.Dockerfile
, unit tests or apyproject.toml
+poetry.lock
file. My personal advice: Overwrite the defaultDockerfile
with yourDockerfile
, delete thepoetry.lock
and merge thepyproject.toml
which mainly adds the cookietemple dev dependencies, then recreate thepoetry.lock
file bypoetry install
. This is the most critical point in the process. You should know how to use a mergetool, such as vimdiff, which you can configure usinggit config merge.tool vimdiff
. Here, some cookietemple automation could help the average user immensely imo.origin/development
branch and it will contain the cookietemple template as well as your work and commit history.git checkout origin main
andgit merge origin/development
.Important notes:
If you have any other branches to merge, you can always
git checkout development
andgit merge <origin name>/<your arbitrary branch in the exsiting repo>
. Be aware, that your branches do not yet contain the cookietemple templates. It is therefore an option to firstgit checkout <your arbitrary branch in the existing repo>
and thengit merge origin/development
. This also ensures you fix potential merge conflicts on your existing branch prior to merging it on the new development branch.If you follow these instructions, you won't experience any merge conflicts other than the ones mentioned in point 6. Since the history of your main branch in the existing repo is now part of your development branch in the newly created cookietemple repo, you can now start checking out new branches from it without any issues and also merge branches from the existing repo without further problems, as long as they have been checked out from the main branch you used for migration in point 5.
Be aware of merge conflicts when fixing pre-commit hooks on the development branch before merging the other branches you might have in the existing repo . Since the automatic pipelines might do a lot of changes to your code, fixing these later on will be a nightmare. It is therefore recommended to first merge everything into origin/development, then freeze the repo (i.e. tell your collabs they should prepare to feel a Hinkelstein fall on their head if they dare to push / checkout new stuff during that time) until you have fixed all the github actions that fail before you release the repository for further development.
Afterwards, everyone is required to fixing the actions before merging onto development which ensures that you don't need to worry about merge conflicts that exceed the complexity of the occasional conflicts in the future. This is only true of course if everybody does
pip install pre-commit
andpre-commit install
on their local machine or at least usenox
manually before pushing new stuff (which should be the default anyways imo.)The text was updated successfully, but these errors were encountered: