On Mon, Jan 22, 2024 at 1:59 PM Jeff King <peff@xxxxxxxx> wrote: > > On Mon, Jan 22, 2024 at 01:45:05PM -0800, Junio C Hamano wrote: > > > Jeff King <peff@xxxxxxxx> 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. > > 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.
