On Fri, Feb 17, 2017 at 10:24 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: > > Ok so this function here reads a recurse submodules parameter which is > a boolean or it can be set to the word "checkout"? Why does checkout > need its own value separate from true? Just so that we have a synonym? > or so that we can expand on it in the future?
I think eventually we want all the commands that touch the worktree to be able to cope with submodules. Now what should e.g. git-revert --recurse-submodules do? yes == "checkout" means we'd revert the superproject commit and if that commit changed any submodule pointers we'd just "checkout" those states in the submodule. For revert you could also imagine to have git-revert --recurse-submodules=revert-in-subs that would not repoint the submodule pointer to the old state, but would try to revert $OLD..$NEW in the submodule and take the newly reverted state as the new submodule pointer. As I want to focus on checkout first, I went with "yes == checkout" here (or rather the other way round).
