{"thread":{"id":"60782","subject":"Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","startedAt":"2024-01-22T20:46:25Z","lastAt":"2024-01-24T18:58:00Z","messageCount":14,"participants":["Raúl Núñez de Arenas Coronado","Junio C Hamano","Jeff King","Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"487221","messageId":"CAGF1KhWiYX=3R01Odj2yCNgvx=f5+HRCjRJogWf5eBikuATCcg@mail.gmail.com","threadId":"60782","inReplyTo":"CAGF1KhWNaO_TUuCPo2L_HzNnR+FnB1Q4H6_xQ2owoH+SnynzEg@mail.gmail.com","subject":"Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Raúl Núñez de Arenas Coronado","fromEmail":"raulnac@gmail.com","sentAt":"2024-01-22T20:45:46Z","receivedAt":"2024-01-22T20:46:25Z","isPatch":false,"sender":{"key":"raulnac@gmail.com","avatar":"https://gravatar.com/avatar/6d36571f4ecfc6b5ad48e41ca5e6bfe5b80f4aac0efee94a1c5f930a7c3447b4?d=mp&s=160"},"body":"Hi there!\n\nI'm not subscribed to the list, sorry, so I would be more than\ngrateful if I'm CC'd, but I'll check the mailing list archive from\ntime to time for replies. Thanks in advance.\n\nIt is a common practice for Python virtual environments, pytest and\nother tools (not always Python related) to add a '.gitignore' file in\ndirectories these tools create on a repository that should NOT be\ncommitted or tracked. By adding a .gitignore file containing a single\n\"*\", the entire directory is ignored by git. So far, so good.\n\nBut when using 'git ls-files --others --exclude-from=', when\n is one of those .gitignore files present in a subdir, makes the\ncommand use the patterns in that .gitgnore (in this case, the \"*\")\nagainst ALL files that would otherwise be listed by using '--others'.\n\nIn short: using 'git ls-files --others\n--exclude-from=subdir/.gitignore' results in an empty listing if\nsubdir/.gitignore contains '*\". IMHO that pattern should be applied to\nthe subdir contents and not to the contents of the current directory.\nThat would be consistent with how git uses .gitignore files in\nsubfolders.\n\nThe obvious solution is to use --exclude-per-directory but it is\ndeprecated in favor of --exclude-standard and --exclude-standard shows\nthe same behaviour of --exclude-from=subdir/.gitignore!!!\n\nIs there any way, not using --exclude-per-directory, of listing all\nuntracked files in the current repository, but ignoring those matching\n.gitignore files with the patterns matching the corresponding\nsubdirectory?\n\nIs this a bug or intended behaviour?\n\nThanks a lot in advance :)\n\n-- \nRaúl Núñez de Arenas Coronado\n.\n"},{"id":"487223","messageId":"xmqqfryprsyp.fsf@gitster.g","threadId":"60782","inReplyTo":"CAGF1KhWiYX=3R01Odj2yCNgvx=f5+HRCjRJogWf5eBikuATCcg@mail.gmail.com","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-01-22T20:52:46Z","receivedAt":"2024-01-22T20:52:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Raúl Núñez de Arenas Coronado writes:\n\n> In short: using 'git ls-files --others\n> --exclude-from=subdir/.gitignore' results in an empty listing if\n> subdir/.gitignore contains '*\". IMHO that pattern should be applied to\n> the subdir contents ...\n\nI do not think so.\n\nImagine what would happen then if you did\n\n $ cp subdir/.gitignore /var/tmp/1\n $ git ls-files --others --exclude-from=/var/tmp/1\n\nin such a repository? The \"--exclude-from\" option is used to name\nthe contents (set of patterns) that should be used and the path of\nthe file that happens to contain the contents does not matter. So\nyou should get the same output as the ls-files command that was told\nto use \"--exclude-from=subdir/.gitignore\".\n"},{"id":"487225","messageId":"CAGF1KhU=o2rb-tCjZAG278kgoW50NYymsJakUwiMxWTQ33gQYA@mail.gmail.com","threadId":"60782","inReplyTo":"xmqqfryprsyp.fsf@gitster.g","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Raúl Núñez de Arenas Coronado","fromEmail":"raulnac@gmail.com","sentAt":"2024-01-22T21:07:03Z","receivedAt":"2024-01-22T21:07:41Z","isPatch":false,"sender":{"key":"raulnac@gmail.com","avatar":"https://gravatar.com/avatar/6d36571f4ecfc6b5ad48e41ca5e6bfe5b80f4aac0efee94a1c5f930a7c3447b4?d=mp&s=160"},"body":"Hi Junio, and thanks a lot for your reply :)\n\nEl lun, 22 ene 2024 a las 21:52, Junio C Hamano () escribió:\n> Raúl Núñez de Arenas Coronado writes:\n>\n> > In short: using 'git ls-files --others\n> > --exclude-from=subdir/.gitignore' results in an empty listing if\n> > subdir/.gitignore contains '*\". IMHO that pattern should be applied to\n> > the subdir contents ...\n>\n> I do not think so.\n>\n> Imagine what would happen then if you did\n>\n> $ cp subdir/.gitignore /var/tmp/1\n> $ git ls-files --others --exclude-from=/var/tmp/1\n\nI understand this use case, yes. I was thinking about what git itself\ndoes when ignoring files, especially when dealing with .gitgnore files\nin subdirectories, but clearly this needs a different policy, yes.\n\nWhat I needed from this command is a way of backing up some ignored\nfiles. These files should not go into the repository, but I'm using\nthem temporarily for development so it is a good idea to back them up.\nI'll just backup the entire repository instead, is not a big deal :))\n\nAgain, thanks for your reply and your explanation! It's a huge honor\nto be replied to by no less than the Git team leather!\n\n-- \nRaúl Núñez de Arenas Coronado\n.\n"},{"id":"487226","messageId":"20240122213410.GA811766@coredump.intra.peff.net","threadId":"60782","inReplyTo":"CAGF1KhWiYX=3R01Odj2yCNgvx=f5+HRCjRJogWf5eBikuATCcg@mail.gmail.com","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-01-22T21:34:10Z","receivedAt":"2024-01-22T21:34:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 22, 2024 at 09:45:46PM +0100, Raúl Núñez de Arenas Coronado wrote:\n\n> But when using 'git ls-files --others --exclude-from=', when\n> is one of those .gitignore files present in a subdir, makes the\n> command use the patterns in that .gitgnore (in this case, the \"*\")\n> against ALL files that would otherwise be listed by using '--others'.\n>\n> In short: using 'git ls-files --others\n> --exclude-from=subdir/.gitignore' results in an empty listing if\n> subdir/.gitignore contains '*\". IMHO that pattern should be applied to\n> the subdir contents and not to the contents of the current directory.\n> That would be consistent with how git uses .gitignore files in\n> subfolders.\n\nI think Junio covered this with his example, and everything is behaving\nas intended (my mental model is that \"--exclude-from\" is something like\n.git/info/exclude or the core.excludesFile option).\n\nBut...\n\n> The obvious solution is to use --exclude-per-directory but it is\n> deprecated in favor of --exclude-standard and --exclude-standard shows\n> the same behaviour of --exclude-from=subdir/.gitignore!!!\n\n...I'm not sure what's going on here. I would think that both\n--exclude-standard and --exclude-per-directory would do what you want.\n\nFor example, I get:\n\n [setup]\n $ git init\n $ mkdir subdir\n $ echo '*' >subdir/.gitignore\n $ git add -f subdir/.gitignore && git commit -m \"add gitignore\"\n $ touch subdir/file file\n\n [no exclusions]\n $ git ls-files -o\n file\n subdir/file\n\n [use .gitignore]\n $ git ls-files --exclude-per-directory=.gitignore -o\n file\n\n [using standard excludes]\n $ git ls-files --exclude-standard -o\n file\n\nDo you get different results from that toy repo? If not, then what is\ndifferent about your main repo? Do you perhaps have a stray \"*\" match\nsomewhere in .git/info/exclude, etc? Or are you still providing\n--exclude-from in addition to --exclude-standard?\n\n-Peff\n\nPS I hadn't realized that --exclude-per-directory had been marked as\n deprecated. I do agree with e750951e74 (ls-files: guide folks to\n --exclude-standard over other --exclude* options, 2023-01-13) in its\n goal of guiding people to the easiest option, but I don't know that\n there has been any discussion about removing the other ones.\n"},{"id":"487227","messageId":"xmqq5xzlrqoi.fsf@gitster.g","threadId":"60782","inReplyTo":"CAGF1KhU=o2rb-tCjZAG278kgoW50NYymsJakUwiMxWTQ33gQYA@mail.gmail.com","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-01-22T21:42:05Z","receivedAt":"2024-01-22T21:42:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Raúl Núñez de Arenas Coronado writes:\n\n> ... I was thinking about what git itself\n> does when ignoring files, especially when dealing with .gitgnore files\n> in subdirectories, but clearly this needs a different policy, yes.\n\nWhat \"git\" internally does is the equivalent of using the\n\"--exclude-per-directory\" option to honor \".gitignore\" in the\nsubdirectories, and in addition use \".git/info/exclude\" as another\nsource, pretty much the same way as \"--exclude-from\" reads it.\n\n> What I needed from this command is a way of backing up some ignored\n> files. These files should not go into the repository, but I'm using\n> them temporarily for development so it is a good idea to back them up.\n> I'll just backup the entire repository instead, is not a big deal :))\n\nThe current mechanism can be used to list \"ignored\" files that must\nbe left out of the project (e.g. the most obvious one being object\nfiles \"*.o\") but these \"ignored\" files are considered \"expendable\"\n(i.e. Git is allowed to remove it as needed, e.g., when switching\nbranches and need to make room---if you have an untracked file F\nthat is ignored, checking out a branch that has a file F/G requires\nthe file F to disappear so that a directory can be created there).\n\nWe have been discussing to extend the mechanism so that we can have\n\"precious\" files, which also will be left out of the project (e.g.,\n\"git add .\" will not add to the index, just like an ignored file)\nbut are not considered \"expendable\". If file F is \"precious\":\n\n - \"git add .\" will not add F to the index\n\n - \"git status\" will not say F is left untracked and can be added\n\n - \"git clean -f\" will not remove it.\n\n - checking out a branch with a tracked file F/G will *fail*, to\n prevent the loss of file.\n\nNo code yet, but the design consensus is almost there. Once it\nappears, you should be able to say \"give me the list of tracked and\nprecious paths---I do not care about ignored ones that are expendable,\nbecause they can be recreated mechanically and that is why they are\nmarked ignored\", and from such a list of files, you should be able\nto drive your back-up solution.\n\n[jc: cc'ed those who are involved in the \"precious\" discussion].\n\n\n"},{"id":"487228","messageId":"xmqq1qa9rqji.fsf@gitster.g","threadId":"60782","inReplyTo":"20240122213410.GA811766@coredump.intra.peff.net","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-01-22T21:45:05Z","receivedAt":"2024-01-22T21:45:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> PS I hadn't realized that --exclude-per-directory had been marked as\n> deprecated. I do agree with e750951e74 (ls-files: guide folks to\n> --exclude-standard over other --exclude* options, 2023-01-13) in its\n> goal of guiding people to the easiest option, but I don't know that\n> there has been any discussion about removing the other ones.\n\nI do not think there is any value in _removing_ the perfectly well\nworking --exclude* options, even though I think --exclude-standard\nshould be what users and scriptors should be using if they want to\nemulate what Git does internally.\n\n"},{"id":"487229","messageId":"20240122215954.GA813833@coredump.intra.peff.net","threadId":"60782","inReplyTo":"xmqq1qa9rqji.fsf@gitster.g","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-01-22T21:59:54Z","receivedAt":"2024-01-22T21:59:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jan 22, 2024 at 01:45:05PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > PS I hadn't realized that --exclude-per-directory had been marked as\n> > deprecated. I do agree with e750951e74 (ls-files: guide folks to\n> > --exclude-standard over other --exclude* options, 2023-01-13) in its\n> > goal of guiding people to the easiest option, but I don't know that\n> > there has been any discussion about removing the other ones.\n> \n> I do not think there is any value in _removing_ the perfectly well\n> working --exclude* options, even though I think --exclude-standard\n> should be what users and scriptors should be using if they want to\n> emulate what Git does internally.\n\nYeah, mostly I was surprised that e750951e74 used as strong a word as\n\"deprecated\".\n\n-Peff\n"},{"id":"487246","messageId":"CAGF1KhWaOrnV8d2f_vajOT0hFK2N_8m7-p_vnZhw92ZdhXfsag@mail.gmail.com","threadId":"60782","inReplyTo":"20240122213410.GA811766@coredump.intra.peff.net","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Raúl Núñez de Arenas Coronado","fromEmail":"raulnac@gmail.com","sentAt":"2024-01-23T05:40:10Z","receivedAt":"2024-01-23T05:40:47Z","isPatch":false,"sender":{"key":"raulnac@gmail.com","avatar":"https://gravatar.com/avatar/6d36571f4ecfc6b5ad48e41ca5e6bfe5b80f4aac0efee94a1c5f930a7c3447b4?d=mp&s=160"},"body":"Hi Jeff, and thanks for your reply :)\n\nEl lun, 22 ene 2024 a las 22:34, Jeff King () escribió:\n> For example, I get:\n>\n> [setup]\n> $ git init\n> $ mkdir subdir\n> $ echo '*' >subdir/.gitignore\n> $ git add -f subdir/.gitignore && git commit -m \"add gitignore\"\n> $ touch subdir/file file\n>\n> [no exclusions]\n> $ git ls-files -o\n> file\n> subdir/file\n>\n> [use .gitignore]\n> $ git ls-files --exclude-per-directory=.gitignore -o\n> file\n>\n> [using standard excludes]\n> $ git ls-files --exclude-standard -o\n> file\n>\n> Do you get different results from that toy repo? If not, then what is\n> different about your main repo? Do you perhaps have a stray \"*\" match\n> somewhere in .git/info/exclude, etc? Or are you still providing\n> --exclude-from in addition to --exclude-standard?\n\nThe difference lies in how I deal in my computer with ignored files. I\nhave some files in all my repos which have to be ignored always, so I\nhave that pattern in my core.excludes file. BUT those files have to be\nbacked up on my system, just in case my local copy of the repo is lost\nfor some reason, as they are files I need for development in my\npersonal machine.\n\nIf I use --exclude-standard, no matter if those files are being\nignored by core.excludes OR .git/info/exclude, they won't appear in\nthat 'list other files' command output.\n\nSo, my previous idea was ignore ONLY those files ignored by the\nrepository .gitignore file. That way, the other files that go in my\ncore.excludes or .git/info/exclude will be listed and backed up. The\nproblem here is that some of the repository gitignored files (files\nrelated to building, testing, etc.) have their own .gitignore file\ncontaining '*\", but they are NOT present in the repo .gitignore. This\nis a common practice for Python virtual environments, for example.\n\nSumming up: or I end up backing up those directories that have their\nown .gitignore file (not the end of the world) or I use a different\nsolution to decide which files are ignored but \"precious\" (I love that\nconcept, see Junio C Hamano message for that) OR I add those\ndirectories to the .gitignore present in the repo. This last idea I\ndon't like very much, as they are particular to my system, not the\nrepo, for example, *I* may decide to use ESLint and node_modules for\nsome particular web page I'm writing, but the related configuration\nshould not go into the repository and should not be ignored in\n.gitignore, but in .git/info/exclude. I won't backup node_modules, of\ncourse, it is going to be recreated, but I may want to back up\npackages.json and .eslintrc. And both of those files will go into\n.git/info/exclude, so if I use --exclude-standard, they won't be\nbacked up.\n\nSince as both Junio and you correctly pointed, this is in fact the\nexpected, I'll try to find a different solution while the \"precious\"\nconcept is finally implemented. I have a couple of ideas, like using a\n.giprecious file which my backup script can process easily, containing\nthe untracked files to back-up.\n\nThanks for the toy repo, helped me test the differences with my setup!\n\n-- \nRaúl Núñez de Arenas Coronado\n.\n"},{"id":"487247","messageId":"CAGF1KhWEnbOy1DQhv4xbov5Fg+hQdihWcwcT9A0f1b4Fc1gR-w@mail.gmail.com","threadId":"60782","inReplyTo":"xmqq5xzlrqoi.fsf@gitster.g","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Raúl Núñez de Arenas Coronado","fromEmail":"raulnac@gmail.com","sentAt":"2024-01-23T06:08:32Z","receivedAt":"2024-01-23T06:09:09Z","isPatch":false,"sender":{"key":"raulnac@gmail.com","avatar":"https://gravatar.com/avatar/6d36571f4ecfc6b5ad48e41ca5e6bfe5b80f4aac0efee94a1c5f930a7c3447b4?d=mp&s=160"},"body":"Hi Junio!\n\nEl lun, 22 ene 2024 a las 22:42, Junio C Hamano () escribió:\n> We have been discussing to extend the mechanism so that we can have\n> \"precious\" files, which also will be left out of the project (e.g.,\n> \"git add .\" will not add to the index, just like an ignored file)\n> but are not considered \"expendable\". If file F is \"precious\":\n>\n> - \"git add .\" will not add F to the index\n>\n> - \"git status\" will not say F is left untracked and can be added\n>\n> - \"git clean -f\" will not remove it.\n>\n> - checking out a branch with a tracked file F/G will *fail*, to\n> prevent the loss of file.\n\nAnd that is exactly the concept I'm handling here: files that should\nnot be tracked BUT that are not expendable. You explained it concisely\nand perfectly :)))\n\nI'll wait until that is implemented, and in the meantime I have a\ncouple solutions I want to try, like using .gitprecious files and 'git\nls-files --other --ignored --exclude-from=.gitprecious'. I have more\nideas.\n\nThanks a lot for the help and the explanation!\n\n-- \nRaúl Núñez de Arenas Coronado\n.\n"},{"id":"487290","messageId":"20240124010924.GB2603087@coredump.intra.peff.net","threadId":"60782","inReplyTo":"CAGF1KhWaOrnV8d2f_vajOT0hFK2N_8m7-p_vnZhw92ZdhXfsag@mail.gmail.com","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-01-24T01:09:24Z","receivedAt":"2024-01-24T01:09:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 23, 2024 at 06:40:10AM +0100, Raúl Núñez de Arenas Coronado wrote:\n\n> > Do you get different results from that toy repo? If not, then what is\n> > different about your main repo? Do you perhaps have a stray \"*\" match\n> > somewhere in .git/info/exclude, etc? Or are you still providing\n> > --exclude-from in addition to --exclude-standard?\n> \n> The difference lies in how I deal in my computer with ignored files. I\n> have some files in all my repos which have to be ignored always, so I\n> have that pattern in my core.excludes file. BUT those files have to be\n> backed up on my system, just in case my local copy of the repo is lost\n> for some reason, as they are files I need for development in my\n> personal machine.\n> \n> If I use --exclude-standard, no matter if those files are being\n> ignored by core.excludes OR .git/info/exclude, they won't appear in\n> that 'list other files' command output.\n\nAh, OK. I understand your case better now. Then yes, I think\n--exclude-per-directory is the right thing for you, since it lets you\njust trigger parts of the exclusion mechanism, and not all. I would say\nto ignore the deprecation mention in the manpage. ;)\n\n(I think this also gives an interesting use case arguing for continuing\nto support those more-specific exclusion options for ls-files).\n\nIf you are mostly just using core.excludesFile (and not\n.git/info/exclude), then I suspect:\n\n git -c core.excludesFile /dev/null ls-files -o --exclude-standard\n\nwould work for you, too (but it sounds like you might also be using\n.git/info/exclude).\n\n-Peff\n"},{"id":"487291","messageId":"CABPp-BHcdn3+mbPJk8LZvMjPWZ4s-xdUyevrMbgbT4yQpJ_umA@mail.gmail.com","threadId":"60782","inReplyTo":"20240122215954.GA813833@coredump.intra.peff.net","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2024-01-24T02:58:51Z","receivedAt":"2024-01-24T02:59:06Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Jan 22, 2024 at 1:59 PM Jeff King wrote:\n>\n> On Mon, Jan 22, 2024 at 01:45:05PM -0800, Junio C Hamano wrote:\n>\n> > Jeff King writes:\n> >\n> > > PS I hadn't realized that --exclude-per-directory had been marked as\n> > > deprecated. I do agree with e750951e74 (ls-files: guide folks to\n> > > --exclude-standard over other --exclude* options, 2023-01-13) in its\n> > > goal of guiding people to the easiest option, but I don't know that\n> > > there has been any discussion about removing the other ones.\n\nI'm not aware of any discussion either. I certainly had no plans to remove it.\n\n> > I do not think there is any value in _removing_ the perfectly well\n> > working --exclude* options, even though I think --exclude-standard\n> > should be what users and scriptors should be using if they want to\n> > emulate what Git does internally.\n>\n> Yeah, mostly I was surprised that e750951e74 used as strong a word as\n> \"deprecated\".\n\nWell, here's what I was thinking. First, based on wikipedia's\ndefinition of deprecated:\n\n```\nIn several fields, especially computing, deprecation is the\ndiscouragement of use of some terminology, feature, design, or\npractice, typically because it has been superseded or is no longer\nconsidered efficient or safe, without completely removing it or\nprohibiting its use. Typically, deprecated materials are not\ncompletely removed to ensure legacy compatibility or back up practice\nin case new methods are not functional in an odd scenario.\n\nIt can also imply that a feature, design, or practice will be removed\nor discontinued entirely in the future.\n```\n\nSince \"can also imply\" != \"does also imply\", and based on the commit\nmessage of 491a7575f (particularly the part that quotes dcf0c16ef1,\nboth of which were prior work that informed the under discussion\ne750951e74), I thought the use of deprecated was perfectly applicable\nhere.\n"},{"id":"487331","messageId":"CAGF1KhV1Gh6WPG7XiQFfEC+G6VY_9AyH3XVoO6VVhMA6za_y3Q@mail.gmail.com","threadId":"60782","inReplyTo":"20240124010924.GB2603087@coredump.intra.peff.net","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Raúl Núñez de Arenas Coronado","fromEmail":"raulnac@gmail.com","sentAt":"2024-01-24T14:22:46Z","receivedAt":"2024-01-24T14:23:22Z","isPatch":false,"sender":{"key":"raulnac@gmail.com","avatar":"https://gravatar.com/avatar/6d36571f4ecfc6b5ad48e41ca5e6bfe5b80f4aac0efee94a1c5f930a7c3447b4?d=mp&s=160"},"body":"Hi Jeff!\n\nEl mié, 24 ene 2024 a las 2:09, Jeff King () escribió:\n> (I think this also gives an interesting use case arguing for continuing\n> to support those more-specific exclusion options for ls-files).\n>\n> If you are mostly just using core.excludesFile (and not\n> .git/info/exclude), then I suspect:\n>\n> git -c core.excludesFile /dev/null ls-files -o --exclude-standard\n>\n> would work for you, too (but it sounds like you might also be using\n> .git/info/exclude).\n\nIn my case, since I'm also using .git/info/exclude in some repos, this\nwon't work as-is, but you gave me an idea, and I think I can get what\nI need until the \"precious\" mechanism is implemented. It requires a\nbit of hacking in the backup script but is not a big deal and it will\nwork for all my current repos.\n\nThanks for the help!\n\n-- \nRaúl Núñez de Arenas Coronado\n.\n"},{"id":"487337","messageId":"xmqqjznyhd90.fsf@gitster.g","threadId":"60782","inReplyTo":"CABPp-BHcdn3+mbPJk8LZvMjPWZ4s-xdUyevrMbgbT4yQpJ_umA@mail.gmail.com","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-01-24T17:06:51Z","receivedAt":"2024-01-24T17:06:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Elijah Newren writes:\n\n> It can also imply that a feature, design, or practice will be removed\n> or discontinued entirely in the future.\n> ```\n>\n> Since \"can also imply\" != \"does also imply\", and based on the commit\n> message of 491a7575f (particularly the part that quotes dcf0c16ef1,\n> both of which were prior work that informed the under discussion\n> e750951e74), I thought the use of deprecated was perfectly applicable\n> here.\n\nI think we've seen confusions before, more than just once in the\npast, caused by the verb \"deprecate\" in our docs. People, after\nreading \"X is deprecated; use Y instead\", always assumed that X will\neventually be removed, even in contexts where we did not mean it.\n\n------ >8 ----------- >8 ----------- >8 ----------- >8 ------\nSubject: ls-files: avoid the verb \"deprecate\" for individual options\n\nWhen e750951e74f updated the documentation to give greater\nvisibility to the --exclude-standard option, it marked the\n`--exclude-per-directory` option as \"deprecated\". While it\ntechnically is correct that being deprecated does not necessarily\nmean it is planned to be removed later, it seems to cause confusion\nto readers, especially when we merely mean\n\n The option Y can be used to achieve the same thing as the option\n X, so to those of you who aren't familiar with either X or Y, we\n would recommend to use Y.\n\nThis is especially true for `--exclude-standard` vs the combination\nof more granular `--exclude-from` and `--exclude-per-directory`\noptions. It is true that one common combination of the granular\noptions can be obtained by just giving the former, but that does not\nnecessarily mean a more granular control is not necessary.\n\nState why we recommend looking at `--exclude-standard` when we do so\nin the description of `--exclude-per-directory`, instead of saying\nthat the option is deprecated. Also, spell out the recipe to emulate\nwhat `--exclude-standard` does, so that the users can give it minute\ntweaks (like \"not reading the global exclusion file from core.excludes\").\n\nSigned-off-by: Junio C Hamano \n---\n Documentation/git-ls-files.txt | 24 +++++++++++++++++++-----\n 1 file changed, 19 insertions(+), 5 deletions(-)\n\ndiff --git c/Documentation/git-ls-files.txt w/Documentation/git-ls-files.txt\nindex f65a8cd91d..93a0111cfb 100644\n--- c/Documentation/git-ls-files.txt\n+++ w/Documentation/git-ls-files.txt\n@@ -119,8 +119,10 @@ OPTIONS\n \n --exclude-per-directory=::\n \tRead additional exclude patterns that apply only to the\n-\tdirectory and its subdirectories in . Deprecated; use\n-\t--exclude-standard instead.\n+\tdirectory and its subdirectories in . If you are\n+\ttrying to emulate the way how Porcelain commands work,\n+\tusing the `--exclude-standard` instead is easier and more\n+\tthorough.\n \n --exclude-standard::\n \tAdd the standard Git exclusions: .git/info/exclude, .gitignore\n@@ -298,9 +300,8 @@ traversing the directory tree and finding files to show when the\n flags --others or --ignored are specified. linkgit:gitignore[5]\n specifies the format of exclude patterns.\n \n-Generally, you should just use --exclude-standard, but for historical\n-reasons the exclude patterns can be specified from the following\n-places, in order:\n+These exclude patterns can be specified from the following places,\n+in order:\n \n 1. The command-line flag --exclude= specifies a\n single pattern. Patterns are ordered in the same order\n@@ -322,6 +323,19 @@ top of the directory tree. A pattern read from a file specified\n by --exclude-per-directory is relative to the directory that the\n pattern file appears in.\n \n+Generally, you should be able to use `--exclude-standard` when you\n+want the exclude rules applied the same way as what Porcelain\n+commands do. To emulate what `--exclude-standard` specifies, you\n+can give `--exclude-per-directory=.gitignore`, and then specify:\n+\n+ 1. The file specified by the `core.excludesfile` configuration\n+ variable, if exists, or the `$XDG_CONFIG_HOME/git/ignore` file.\n+\n+ 2. The `$GIT_DIR/info/exclude` file \n+\n+via the `--exclude-from=` option.\n+\n+\n SEE ALSO\n --------\n linkgit:git-read-tree[1], linkgit:gitignore[5]\n"},{"id":"487343","messageId":"20240124185754.GA21980@coredump.intra.peff.net","threadId":"60782","inReplyTo":"xmqqjznyhd90.fsf@gitster.g","subject":"Re: Fwd: Unexpected behavior of ls-files command when using --others --exclude-from, and a .gitignore file which resides in a subdirectory","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2024-01-24T18:57:54Z","receivedAt":"2024-01-24T18:58:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 24, 2024 at 09:06:51AM -0800, Junio C Hamano wrote:\n\n> ------ >8 ----------- >8 ----------- >8 ----------- >8 ------\n> Subject: ls-files: avoid the verb \"deprecate\" for individual options\n> \n> When e750951e74f updated the documentation to give greater\n> visibility to the --exclude-standard option, it marked the\n> `--exclude-per-directory` option as \"deprecated\". While it\n> technically is correct that being deprecated does not necessarily\n> mean it is planned to be removed later, it seems to cause confusion\n> to readers, especially when we merely mean\n> \n> The option Y can be used to achieve the same thing as the option\n> X, so to those of you who aren't familiar with either X or Y, we\n> would recommend to use Y.\n> \n> This is especially true for `--exclude-standard` vs the combination\n> of more granular `--exclude-from` and `--exclude-per-directory`\n> options. It is true that one common combination of the granular\n> options can be obtained by just giving the former, but that does not\n> necessarily mean a more granular control is not necessary.\n> \n> State why we recommend looking at `--exclude-standard` when we do so\n> in the description of `--exclude-per-directory`, instead of saying\n> that the option is deprecated. Also, spell out the recipe to emulate\n> what `--exclude-standard` does, so that the users can give it minute\n> tweaks (like \"not reading the global exclusion file from core.excludes\").\n\nThis perfectly sums up the situation from my viewpoint. And I think the\nchanges you suggest not only remove the confusion over the term, they\nlay out the possible options for the user much better.\n\nThe patch looks good to me, modulo one minor comment:\n\n> diff --git c/Documentation/git-ls-files.txt w/Documentation/git-ls-files.txt\n> index f65a8cd91d..93a0111cfb 100644\n> --- c/Documentation/git-ls-files.txt\n> +++ w/Documentation/git-ls-files.txt\n> @@ -119,8 +119,10 @@ OPTIONS\n> \n> --exclude-per-directory=::\n> \tRead additional exclude patterns that apply only to the\n> -\tdirectory and its subdirectories in . Deprecated; use\n> -\t--exclude-standard instead.\n> +\tdirectory and its subdirectories in . If you are\n> +\ttrying to emulate the way how Porcelain commands work,\n> +\tusing the `--exclude-standard` instead is easier and more\n> +\tthorough.\n\nAs a native English speaker, the phrasing here is awkward to me. I'd\nprobably say \"...emulate the way that Porcelain commands work\". Or\nalternatively, \"emulate how Porcelain commands work\".\n\n-Peff\n"}]}