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
This feature request adds a lot of complexity to this project but here it is anyway
PROBLEM:
Suppose you have a constant list of 10 repos you want to use Turbolift for. Each and every campaign you create will result in a new clone of the repos. This takes up unnecessary space on a dev's local drive, plus it's slow to download them over and over.
FEATURE REQUEST:
Allow to define a localpath in repos.txt which indicates a local clone of a repository to be worked on. Use this clone instead of creating a new one in the work directory for every new campaign
ALTERNATIVE APPROACH:
Allow to define a repos.txt (or core_repos.txt) in the root of a turbolift directory (this also invents this concept). These core_repos are what you expect to work on most of the time, and thus shouldn't re-clone everytime. There would also be a work directory beside the core_repos.txt.
The file structure would look something like this:
Thanks a lot for raising this @jansenignacio!
We had a previous internal version of the tool that worked like that based off git worktree and did exactly what you describe. I'll add some more details based on that issue a bit later.
This feature request adds a lot of complexity to this project but here it is anyway
PROBLEM:
Suppose you have a constant list of 10 repos you want to use Turbolift for. Each and every campaign you create will result in a new clone of the repos. This takes up unnecessary space on a dev's local drive, plus it's slow to download them over and over.
FEATURE REQUEST:
Allow to define a localpath in
repos.txt
which indicates a local clone of a repository to be worked on. Use this clone instead of creating a new one in thework
directory for every new campaignALTERNATIVE APPROACH:
Allow to define a
repos.txt
(orcore_repos.txt
) in the root of a turbolift directory (this also invents this concept). Thesecore_repos
are what you expect to work on most of the time, and thus shouldn't re-clone everytime. There would also be awork
directory beside thecore_repos.txt
.The file structure would look something like this:
The text was updated successfully, but these errors were encountered: