git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory

From
Elijah Newren <newren@gmail.com>
Date
Jan 24, 2024, 02:58 UTC
Message-ID
<CABPp-BHcdn3+mbPJk8LZvMjPWZ4s-xdUyevrMbgbT4yQpJ_umA@mail.gmail.com>
In-Reply-To
<20240122215954.GA813833@coredump.intra.peff.net>
On Mon, Jan 22, 2024 at 1:59 PM Jeff King <peff@peff.net> wrote:
Show 10 quoted lines
>
> On Mon, Jan 22, 2024 at 01:45:05PM -0800, Junio C Hamano wrote:
>
> > Jeff King <peff@peff.net> writes:
> >
> > > PS I hadn't realized that --exclude-per-directory had been marked as
> > >    deprecated. I do agree with e750951e74 (ls-files: guide folks to
> > >    --exclude-standard over other --exclude* options, 2023-01-13) in its
> > >    goal of guiding people to the easiest option, but I don't know that
> > >    there has been any discussion about removing the other ones.
I'm not aware of any discussion either.  I certainly had no plans to remove it.
Show 7 quoted lines
> > I do not think there is any value in _removing_ the perfectly well
> > working --exclude* options, even though I think --exclude-standard
> > should be what users and scriptors should be using if they want to
> > emulate what Git does internally.
>
> Yeah, mostly I was surprised that e750951e74 used as strong a word as
> "deprecated".

Well, here's what I was thinking. First, based on wikipedia's definition of deprecated:

``` In several fields, especially computing, deprecation is the discouragement of use of some terminology, feature, design, or practice, typically because it has been superseded or is no longer considered efficient or safe, without completely removing it or prohibiting its use. Typically, deprecated materials are not completely removed to ensure legacy compatibility or back up practice in case new methods are not functional in an odd scenario.

It can also imply that a feature, design, or practice will be removed or discontinued entirely in the future. ```

Since "can also imply" != "does also imply", and based on the commit message of 491a7575f (particularly the part that quotes dcf0c16ef1, both of which were prior work that informed the under discussion e750951e74), I thought the use of deprecated was perfectly applicable here.

Previous: Jeff KingNext: Junio C Hamano
Message 9 of 14 in “Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory”
  1. Raúl Núñez de Arenas CoronadoJan 22, 2024
  2. Junio C HamanoJan 22, 2024
  3. Raúl Núñez de Arenas CoronadoJan 22, 2024
  4. Junio C HamanoJan 22, 2024
  5. Raúl Núñez de Arenas CoronadoJan 23, 2024
  6. Jeff KingJan 22, 2024
  7. Junio C HamanoJan 22, 2024
  8. Jeff KingJan 22, 2024
  9. Elijah NewrenJan 24, 2024
  10. Junio C HamanoJan 24, 2024
  11. Jeff KingJan 24, 2024
  12. Raúl Núñez de Arenas CoronadoJan 23, 2024
  13. Jeff KingJan 24, 2024
  14. Raúl Núñez de Arenas CoronadoJan 24, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.