On Tue, Feb 21, 2017 at 11:42 AM, Stefan Beller <sbel...@google.com> wrote: > 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).
Ok I understand, but this seems like the variable could eventually start to included more and more complex things? For now, "checkout" means "when changing submodules prefer to check out contents" right? I guess that sort of makes some sense. Thanks, Jake
