On Thu, Apr 13, 2017 at 12:25 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: > On Thu, Apr 13, 2017 at 12:12 PM, Jacob Keller <jacob.keller@xxxxxxxxx> wrote: >> On Thu, Apr 13, 2017 at 12:05 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote: >>> On Thu, Apr 13, 2017 at 11:57 AM, Brandon Williams <bmwill@xxxxxxxxxx> wrote: >>>> Add in a check to see if a submodule is active before attempting to >>>> recurse. This prevents 'ls-files' from trying to operate on a submodule >>>> which may not exist in the working directory. >>> >>> What would currently happen on recursing into non-active submodules? >>> Can we have a test for this? >>> >>> Thanks, >>> Stefan >> >> We should be able to test for this. Is it possible that we can recurse >> into a submodule as long as we have the clone in .git/modules/<name> >> even if we don't have it checked out currently? > > Conceptually that should be possible, e.g. > > git ls-files --recurse-submodules <ancient ref> > > where the ancient ref contained submodules that are not present any more. > In that case we would need to do > > struct strbuf sb = STRBUF_INIT; > struct child_process = CHILD_PROCESS_INIT; > struct submodule *sub = submodule_from_path( \ > <path as recorded in ancient tree>, <ancient ref>) > strbuf_git_path(&sb, "modules/%s", sub->name); > > argv_array_pushl(&cp.args, "git", "ls-files", "--recurse", ...); > cp.dir = sb.buf; > run_command(&cp); > > Stefan Never mind. git ls-files doesn't support showing files for a specific ancient history. (I guess you'd use ls-tree for that?). I'm guessing we want to run in the actual work-tree for ls-files here. Does "is_submodule_initialized()" going to ensure that we only operate on a submodule that's currently checked out? Thanks, Jake