From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 12 Sep 2016 01:47:19 GMT
Subject: Re: [RFC/PATCH] ls-files: adding support for submodules
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.