All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: Ilias Apostolou <ilias.apostolou.zero@gmail.com>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: Request feature: –no-submodule
Date: Thu, 03 Jun 2021 09:55:57 +0900	[thread overview]
Message-ID: <xmqq8s3r7oma.fsf@gitster.g> (raw)
In-Reply-To: <YLfqiLbpPXWXHlBi@nand.local> (Taylor Blau's message of "Wed, 2 Jun 2021 16:31:04 -0400")

Taylor Blau <me@ttaylorr.com> writes:

> On Wed, Jun 02, 2021 at 01:31:11PM +0300, Ilias Apostolou wrote:
>> 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.


  reply	other threads:[~2021-06-03  0:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 10:31 Request feature: –no-submodule Ilias Apostolou
2021-06-02 20:31 ` Taylor Blau
2021-06-03  0:55   ` Junio C Hamano [this message]
2021-06-03  2:33     ` Taylor Blau
2021-06-03 10:48       ` Ilias Apostolou
2021-06-03 22:06         ` Junio C Hamano
2021-06-03 17:40       ` Junio C Hamano
2021-06-03 19:22         ` Jeff King
2021-06-03 21:54           ` Junio C Hamano
2021-06-04  4:03             ` Jeff King
2021-06-04  5:06               ` Junio C Hamano
2021-06-05  5:45                 ` Ilias Apostolou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq8s3r7oma.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=ilias.apostolou.zero@gmail.com \
    --cc=me@ttaylorr.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.