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
{{ message }}
Repository navigation
CLI: on new pull, only delete managed files, not all #1077
Addition
The above suggestion stands when the pulled project is the same as the one existing in the /workflow filesystem(the active project in the workspace). Else-if it's a different project being pulled, we warn and clean everything from disk.
I'm not sure what difference it make if it's a new project or a different one? Is there a particular example you're thinking of?
The way I see it, the CLI is tracking certain files before and after checkout. Only those files should be modified by the checkout.
I can imagine it's very useful to be able to leave documentation, state files, outputs, tests in the folder. They might not track particularly well during checkouts, but they might be good enough, and might be tracked in git. But that's the user's problem - we should minimally disrupt the file system as a matter of principle. The implementation we have now is just a quick rushed win.
Activity
doc-han commentedon Oct 22, 2025
Addition
The above suggestion stands when the pulled project is the same as the one existing in the /workflow filesystem(the active project in the workspace). Else-if it's a different project being pulled, we warn and clean everything from disk.
josephjclark commentedon Oct 23, 2025
I'm not sure what difference it make if it's a new project or a different one? Is there a particular example you're thinking of?
The way I see it, the CLI is tracking certain files before and after checkout. Only those files should be modified by the checkout.
I can imagine it's very useful to be able to leave documentation, state files, outputs, tests in the folder. They might not track particularly well during checkouts, but they might be good enough, and might be tracked in git. But that's the user's problem - we should minimally disrupt the file system as a matter of principle. The implementation we have now is just a quick rushed win.