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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 12, 2016, 16:01 UTC
Message-ID: <xmqqmvjd3y5l.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160912005229.6njhgfq7h6cb34s4@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

>> I do not use submodules myself, but I could imagine that you may have
>> scripts outside of git that do not care about the submodule divisions at
>> all, and would be happy with the flat block. ...
>> git-grep does not (I don't use "ack", but perhaps "git ls-files
>> --recurse-submodules -z | xargs --null ack ..." is something people
>> would want to do).
>
> None of that negates your point, btw, which is that this does not seem
> like a great building block for "git grep --recurse-submodules". Just
> that it seems plausible to me that people could find recursive
> "ls-files" useful on its own.

I do think it is a good argument why ls-files (with or without -z) that recurses into submodules would help "git grep" that does not look at the object store and does the search in the working tree files that are tracked. In normal Git world view, if you want a list of files that are tracked, you are the one who is supposed to go to the repository and look at the index there, but if you can somehow magically get that list out-of-band, the "in the working tree files" mode of "git grep" can work just like the "xargs -z ack" pipeline in your example.

So I tend to agree that the enhancement in question is a useful thing on its own, at least the part that gives a list of paths in the index.

I do not know if all other operationg modes are useful, though. For eaxmple, the mode that lists untracked paths might be useful to do a recursive "git clean". On the other hand, "ls-files -s" with the patch may produce the "correct" result (i.e. the object name given for each path would be the same one that are found in the index of the submodule the path was taken from), but the correctness may not necessarily translate to usefulness, exactly because you need to know which submodule's repository has the named object that is not given by the flattened list.

Having to say that "this command produces correct result, but not all correct things are necessarily useful" makes me wonder if that is the direction in which we would want to go. For example, what would be our answer to an end-user question: I now know that the recursive ls-files can give me all the untracked files in the top-level and submodules. How can I feed that to "git add" to update their respective index files with them?

I am not convinced that we would always want to make "git add lib/Makefile" to automagically run "git -C lib/ add Makefile" when lib/ is a submodule (for that matter, even if we wanted to, I do not know if that is something we can efficiently do with pathspecs that have wildcards).

So...