List view
`jj` has all of the necessary machinery to support all of the workflows of readonly submodules (i.e. users cannot create new objects in a submodule), for example: - Submodules can be cloned anew - Submodules can be deleted - New submodule commits can be fetched - Submodule history and branches can be viewed - Submodule contents can be populated in the working copy - Superproject gitlink can be updated to an existing submodule commit - Conflicts in the superproject gitlink can be resolved to an existing submodule commit The user-facing functionality should be accessible using debug-only commands and be very low-level. E.g., - we may have a command to clone a given submodule by its name, but `jj git clone` won't automatically look for submodules and clone them - we may have a command to populate a submodule's contents in the working copy, but `jj new` won't do it automatically When we define what our desired workflows will be, some of these debug-only commands may be eventually exposed to end users.
No due date•0/4 issues closedUsers can have their readonly submodules automatically managed for them by just running regular `jj` commands and trusting that `jj` will automatically recurse into submodules and do the right thing. This requires some definition of what the "right thing" is, especially in unhappy paths, e.g.: - `jj git clone` should automatically clone submodules, but what happens if the submodule clone fails because the submodule is no longer available? - `jj checkout` should update the working copy, but what happens if the submodule hasn't been cloned yet or the submodule commit is missing?
No due date•0/5 issues closed