Feature idea
For UX of #714 we should change our setup process (e.g. ide create «project» «git-url»).
In the future, we should
- clone the given git-url to a temporary directory (maybe below
$IDE_ROOT/_ide/tmp/)
- analyse the result:
- Did git clone fail? (--> invalid, abort)
- Does the content look like regular settings? (--> fine, move to
$IDE_HOME/settings)
- Does the content look like a code repo with settings? (--> fine, move to
$IDE_HOME/workspaces/main/«repo-name» and link to $IDE_HOME/settings like with --code option on ide create)
- Is this neither one of the 2 above? (--> invalid, abort, no settings found in «git-url»)
- If valid now we only create the project folder (
$IDE_HOME = $IDE_ROOT/«project») and start populating it (see existing code and see points above to create settings via move/link).
This has several advantages:
- if the cloning fails or the cloned repo is non-sense, we have not yet created a project that the user then needs to manually delete.
- we can get rid of the
--code option entirely since IDEasy becomes smart enough to detect this automatically without the need for such option flag.
- the user gets better error feedback if he did something odd.
Additional context
Be aware that this needs to be done in AbstractUpdateCommandlet that is shared and reused from both CreateCommandlet and UpdateCommandlet.
So we have to properly consider if the project already exists and settings are already there or not.
However, if settings is just an empty folder, we consider it as not there (and can also delete it).
In such cases we go for the cloning and behave as described above.
Otherwise we just (try to) update (pull) the settings and that should not be changed when implementing this story.
Feature idea
For UX of #714 we should change our setup process (e.g.
ide create «project» «git-url»).In the future, we should
$IDE_ROOT/_ide/tmp/)$IDE_HOME/settings)$IDE_HOME/workspaces/main/«repo-name»and link to$IDE_HOME/settingslike with--codeoption onide create)$IDE_HOME=$IDE_ROOT/«project») and start populating it (see existing code and see points above to createsettingsvia move/link).This has several advantages:
--codeoption entirely since IDEasy becomes smart enough to detect this automatically without the need for such option flag.Additional context
Be aware that this needs to be done in
AbstractUpdateCommandletthat is shared and reused from bothCreateCommandletandUpdateCommandlet.So we have to properly consider if the project already exists and
settingsare already there or not.However, if
settingsis just an empty folder, we consider it as not there (and can also delete it).In such cases we go for the cloning and behave as described above.
Otherwise we just (try to) update (pull) the
settingsand that should not be changed when implementing this story.