previous work: https://public-inbox.org/git/20161203003022.29797-1-sbeller@xxxxxxxxxx/ v4: * addressed all comments of Brian, Junio and Brandon. Thanks! * one major point of change is the introduction of another patch "lib-submodule-update.sh: do not use ./. as submodule remote", as that took some time to track down the existing bug. v3: * moved tests from t2013 to the generic submodule library. * factored out the refactoring patches to be up front * As I redid the complete implementation, I have the impression this time it is cleaner than previous versions. I think we still have to fix the corner cases of directory/file/submodule conflicts before merging, but this serves as a status update on my current way of thinking how to implement the worktree commands being aware of submodules. Thanks, Stefan v2: * based on top of the series sent out an hour ago "[PATCHv4 0/5] submodule embedgitdirs" * Try to embed a submodule if we need to remove it. * Strictly do not change behavior if not giving the new flag. * I think I missed some review comments from v1, but I'd like to get the current state out over the weekend, as a lot has changed so far. On Monday I'll go through the previous discussion with a comb to see if I missed something. v1: When working with submodules, nearly anytime after checking out a different state of the projects, that has submodules changed you'd run "git submodule update" with a current version of Git. There are two problems with this approach: * The "submodule update" command is dangerous as it doesn't check for work that may be lost in the submodule (e.g. a dangling commit). * you may forget to run the command as checkout is supposed to do all the work for you. Integrate updating the submodules into git checkout, with the same safety promises that git-checkout has, i.e. not throw away data unless asked to. This is done by first checking if the submodule is at the same sha1 as it is recorded in the superproject. If there are changes we stop proceeding the checkout just like it is when checking out a file that has local changes. The integration happens in the code that is also used in other commands such that it will be easier in the future to make other commands aware of submodule. This also solves d/f conflicts in case you replace a file/directory with a submodule or vice versa. The patches are still a bit rough, but the overall series seems promising enough to me that I want to put it out here. Any review, specifically on the design level welcome! Thanks, Stefan Stefan Beller (14): lib-submodule-update.sh: reorder create_lib_submodule_repo lib-submodule-update.sh: define tests for recursing into submodules make is_submodule_populated gently connect_work_tree_and_git_dir: safely create leading directories update submodules: add submodule config parsing update submodules: add a config option to determine if submodules are updated update submodules: introduce is_interesting_submodule update submodules: move up prepare_submodule_repo_env update submodules: add submodule_go_from_to unpack-trees: pass old oid to verify_clean_submodule unpack-trees: check if we can perform the operation for submodules read-cache: remove_marked_cache_entries to wipe selected submodules. entry.c: update submodules when interesting builtin/checkout: add --recurse-submodules switch Documentation/git-checkout.txt | 7 + builtin/checkout.c | 28 +++ builtin/grep.c | 2 +- dir.c | 2 + entry.c | 28 +++ read-cache.c | 3 + submodule-config.c | 22 ++ submodule-config.h | 17 +- submodule.c | 216 +++++++++++++++-- submodule.h | 16 +- t/lib-submodule-update.sh | 534 +++++++++++++++++++++++++++++++++++++++-- t/t2013-checkout-submodule.sh | 5 + unpack-trees.c | 115 +++++++-- unpack-trees.h | 1 + 14 files changed, 936 insertions(+), 60 deletions(-) -- 2.12.0.rc0.16.gd1691994b4.dirty