Re: [RFC/PATCH] ls-files: adding support for submodules

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 12, 2016, 01:47 UTC
Message-ID: <xmqqlgyx6g9k.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <xmqqmvje6qbe.fsf@gitster.mtv.corp.google.com>

Junio C Hamano <gitster@pobox.com> writes:

> So a "ls-files" that is done internally in the end-user facing "git
> grep --recurse-submodules" needs to be run _without_ recursing
> itself at least once to learn "lib/" is a submodule.  A flat "here
> are everything we have" does not sound like a good building block.

... unless you are _only_ interested in grepping (or in general working outside Git repository) in the files in the working tree, i.e. "git grep" without <tree-ish> nor "--cached".

A lot of the time you are interested in the current state of files, not even in "the state recorded in the tip of the history" but in "the state as I have in my working tree, the state as my compiler sees it".

I am a bit torn. Clearly this is an important special case, but it would make the codepath for object database case and working tree case even further apart between "git grep [--cached | <tree-ish>]" and the "find in the working tree" codepath, which does not sound friendly to the codebase.