All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Philippe Blain <levraiphilippeblain@gmail.com>
Cc: Philippe Blain via GitGitGadget <gitgitgadget@gmail.com>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] ls-files: respect 'submodule.recurse' config
Date: Fri, 11 Sep 2020 12:19:15 -0700	[thread overview]
Message-ID: <xmqqk0x0nmto.fsf@gitster.c.googlers.com> (raw)
In-Reply-To: <45EB4E9E-1819-41D6-839E-A3812456478C@gmail.com> (Philippe Blain's message of "Fri, 11 Sep 2020 09:05:42 -0400")

Philippe Blain <levraiphilippeblain@gmail.com> writes:

> I understand, but I would argue that such a user could easily adapt their
> script to add '--no-recurse-submodules' to their ls-files invocation if that 
> is the case, no ?

It would have been quite a different story if we were designing
"ls-files" and adding support for "--[no-]recurse-submodules" and
"submodule.recurse" to the command at the same time.  To those who
write scripts with "ls-files" and complain that the command behaves
differently depending on the configuration, you can legitimately say
"you can use --no-recurse-submodules and you are fine" in that case.

But not after all these years.  The same statement becomes "even if
I broke the command, users could work around the breakage I caused".
That is nothing more than a lame excuse that does not explay why you
think you have the right to break their script in the first place.

So, no, I am not enthused to see this change.  Regardless of which
configuration variable affects the feature.  For those who wrote and
use scripts that run ls-files, it is a regression to invite unneeded
complaints from their end-users who suddenly see the breakage in the
scripts.




  reply	other threads:[~2020-09-11 19:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-10  3:07 [PATCH] ls-files: respect 'submodule.recurse' config Philippe Blain via GitGitGadget
2020-09-10  4:25 ` Junio C Hamano
2020-09-10  4:50   ` Junio C Hamano
2020-09-11 13:11     ` Philippe Blain
2020-09-11 14:30     ` Philippe Blain
2020-09-11 13:05   ` Philippe Blain
2020-09-11 19:19     ` Junio C Hamano [this message]
2020-09-13 10:47     ` Đoàn Trần Công Danh
2020-09-13 10:51       ` Đoàn Trần Công Danh
2020-09-11 13:48   ` Philippe Blain

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=xmqqk0x0nmto.fsf@gitster.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=levraiphilippeblain@gmail.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.