Re: Request feature: –no-submodule

Taylor Blau [off-list ref] writes:

On Wed, Jun 02, 2021 at 01:31:11PM +0300, Ilias Apostolou wrote:

quoted

Hello Git community.

As you already know, git ls-files command lists all of the tracked files,
but submodule names are included.

My team would like a –no-submodule switch to exclude those.

In all honesty, though this seems like a niche request for ls-files to
fulfill, ls-files already has quite the collection of options, so I
wouldn't be sad to see it learn how to do this, too.

I would be somewhat sad for two reasons.

 - If "I am not interested in any submodule" in a project with
   submodules is a common thing people would want, teaching a trick
   only to "ls-files" is an expensive and ineffective approach, and
   adding the option to everything would just be ugly.  "git diff
   --no-submodule"?  "git add --no-submodule ."?

 - Is "not interested in any submodule" so special and fundamental,
   or is it merely because the project the original requestor is
   looking at happens to have an optional submodule? If the project
   had that optional part as a subdirectory instead, would the
   request have been not --no-submodule but something else?  What
   happens when the project that led to the original request
   acquires another submodule that is more interesting, or what if
   the requestor's interest shifts and makes some submodules
   interesting but others not?  Would the --no-submodule option
   become totally useless in such a case?

I wonder if the "attr" magic of the pathspec, that allows you to
choose paths based on the attributes you set on them, is what the
original requestor missed.

On Thu, Jun 03, 2021 at 09:55:57AM +0900, Junio C Hamano wrote:

Taylor Blau [off-list ref] writes:

quoted

In all honesty, though this seems like a niche request for ls-files to
fulfill, ls-files already has quite the collection of options, so I
wouldn't be sad to see it learn how to do this, too.

I would be somewhat sad for two reasons.

Mmm, that's a convincing set of reasons to think that this is a bad
idea. (And I was sort of on the fence about it anyway by posting the
whole thing as a short diff instead of a polished patch).

I wonder if the "attr" magic of the pathspec, that allows you to
choose paths based on the attributes you set on them, is what the
original requestor missed.

Maybe... but relying on the attr magic for this particular case would
force the requester to set that attribute on all submodules in their
project, and constantly keep that in-sync with their .gitmodules. So, it
certainly make it easier to handle a request like "I don't care about
ls-files telling me about any submodule(s) except these ones", but
perhaps at the expense of some extra bookkeeping.

I might be missing something, though.

Thanks,
Taylor

The reason we need to list all of the true files (except submodules) is 
for code refactoring using the sed unility, for example:

git ls-files | grep -Ev '(png$|ico$)' | xargs sed -i 's/\r\n/\n/'

All of the other alternatives we could think of are very ugly.

On 3/6/2021 5:33 π.μ., Taylor Blau wrote:

On Thu, Jun 03, 2021 at 09:55:57AM +0900, Junio C Hamano wrote:

quoted

Taylor Blau [off-list ref] writes:

quoted

In all honesty, though this seems like a niche request for ls-files to
fulfill, ls-files already has quite the collection of options, so I
wouldn't be sad to see it learn how to do this, too.

I would be somewhat sad for two reasons.

In my opinion, this should be a feature for "ls-files" only, since it 
would be nice to have a clean stream of true files.

Thank you for your replies,
Ilias

Taylor Blau [off-list ref] writes:

Mmm, that's a convincing set of reasons to think that this is a bad
idea. (And I was sort of on the fence about it anyway by posting the
whole thing as a short diff instead of a polished patch).

quoted

I wonder if the "attr" magic of the pathspec, that allows you to
choose paths based on the attributes you set on them, is what the
original requestor missed.

Maybe... but relying on the attr magic for this particular case would
force the requester to set that attribute on all submodules in their
project, and constantly keep that in-sync with their .gitmodules.

Well, it contradicts with the above "convincing" adjective, and
shows that you are not convinced that "submodule"-ness is not all
that essential and it merely is an artifact that the paths that the
original requester happens to be uninterested in are all submodules.

But if we agree that focusing too narrowly on "submodule"-ness is a
bad idea and open our mind to elsewhere, we'd realize that once we
learn that we can "mark" any path with attributes and use that in
magic pathspec, we can mark not just submodules but a subdirectory
as "uninteresting", which will not become useless even when it turns
out that "submodule"-ness wasn't really what the request was about.

Besides, you can iterate over the available submodules with "git
submodule foreach" fairly mechanically, and maintaining the
attribute per path shouldn't be all that hard, I would imagine.

On Fri, Jun 04, 2021 at 02:40:25AM +0900, Junio C Hamano wrote:

Besides, you can iterate over the available submodules with "git
submodule foreach" fairly mechanically, and maintaining the
attribute per path shouldn't be all that hard, I would imagine.

It doesn't seem outrageous to me for Git to automatically populate
"pseudo-attributes" that connect properties of paths to the attribute
system. I.e., could we just act as if every path that is a gitlink has
the "gitlink" attribute set to true, and let people do:

  git ls-files ':(attr:-gitlink)'

That uses the existing generic mechanism, so it supports complex
situations, but it also makes the "easy" case of "just ignore
submodules" easy, with no attribute maintenance.

I didn't look at the code, though, so I'm not sure how awkward it would
be to implement (usually we decide on attributes only from looking at
the attribute files, not the trees/index themselves, but I think most
code asking about a path would be iterating a list of files in the first
place, and could feed the mode information).

An alternative view is allowing a pathspec that asks about the mode:

  git ls-files ':(mode=160000)'

That also lets you ask about other things, like:

  git ls-files ':(mode=100755)'

but it is probably unnecessarily arcane (even I had to look up the
correct mode for a gitlink just now :) ).

-Peff