# A new feature command request `cmd_ignore` 5 messages from 2022-01-14 to 2022-01-15. Participants: Jaydeep Das, Elijah Newren, Johannes Sixt. Thread: https://gitlist.dev/t/57247 ## Jaydeep Das, 2022-01-14 18:58 Subject: A new feature command request `cmd_ignore` Message-ID: <11860e44-beff-39e6-2efc-53324223caee@gmail.com> URL: https://gitlist.dev/e/11860e44-beff-39e6-2efc-53324223caee%40gmail.com ``` Generally, To ignore files from a repository, we just have to add the file name in `.gitignore`. But this task becomes a bit tedious when there are a lot of unstaged files which you want to ignore. `git ignore [file names]` would add that file to `.gitignore` and other parameters like `--force` could be added which would delete that file cache if that file was already committed. This is my very first mail in the mailing list and I look forward to becoming a future contributor to the git project. I would like to hear your opinions on this command and would like to implement it if approved. Regards, Jaydeep. ``` ## Elijah Newren, 2022-01-15 05:17 Subject: Re: A new feature command request `cmd_ignore` Message-ID: URL: https://gitlist.dev/e/CABPp-BFY2issEqOj1Oj71k%3D494vc8E563CndxPZfXYrteFoNhw%40mail.gmail.com In-Reply-To: <11860e44-beff-39e6-2efc-53324223caee@gmail.com> ``` On Fri, Jan 14, 2022 at 3:03 PM Jaydeep Das wrote: > > Generally, To ignore files from a repository, we just have to add the > file name in `.gitignore`. But this task becomes a bit > tedious when there are a lot of unstaged files which you want to ignore. 'unstaged' implies the file is tracked (i.e. previously added), but has local changes. I think you mean 'untracked' here. > `git ignore [file names]` > > would add that file to `.gitignore` If there are lots of untracked files, why is it less tedious to type all of them on the command line, then to type all of them in the .gitignore file? I don't see what effort is being saved. > and other parameters like `--force` > could be added which would delete that file cache if that > file was already committed. I don't understand what you mean by this. ``` ## Johannes Sixt, 2022-01-15 09:03 Subject: Re: A new feature command request `cmd_ignore` Message-ID: <5f6f1dba-a923-4bb9-70a7-4936566f46e0@kdbg.org> URL: https://gitlist.dev/e/5f6f1dba-a923-4bb9-70a7-4936566f46e0%40kdbg.org In-Reply-To: ``` Am 15.01.22 um 06:17 schrieb Elijah Newren: > On Fri, Jan 14, 2022 at 3:03 PM Jaydeep Das wrote: >> and other parameters like `--force` >> could be added which would delete that file cache if that >> file was already committed. > > I don't understand what you mean by this. I think that is a paraphrase of the suggestion to git rm --cached settings echo settings >> .gitignore when changes to a file 'settings' that was already tracked (and often contains user-specific settings) should be ignored. This misguided and short-sighted "solution" is repeated numerous times on Stackoverflow. Not something that we should encourage. -- Hannes ``` ## Jaydeep Das, 2022-01-15 10:45 Subject: Re: A new feature command request `cmd_ignore` Message-ID: <9a3837b4-8c67-e114-e977-f6c7b729ba45@gmail.com> URL: https://gitlist.dev/e/9a3837b4-8c67-e114-e977-f6c7b729ba45%40gmail.com In-Reply-To: <5f6f1dba-a923-4bb9-70a7-4936566f46e0@kdbg.org> ``` > I think that is a paraphrase of the suggestion to git rm --cached settings echo settings >> .gitignore > when changes to a file 'settings' that was already tracked (and often > contains user-specific settings) should be ignored. This misguided and > short-sighted "solution" is repeated numerous times on Stackoverflow. > Not something that we should encourage. So what should be done in this scenario? And why is it a discouraged and misguided thing? On 1/15/22 14:33, Johannes Sixt wrote: > Am 15.01.22 um 06:17 schrieb Elijah Newren: >> On Fri, Jan 14, 2022 at 3:03 PM Jaydeep Das wrote: >>> and other parameters like `--force` >>> could be added which would delete that file cache if that >>> file was already committed. >> I don't understand what you mean by this. > I think that is a paraphrase of the suggestion to > > git rm --cached settings > echo settings >> .gitignore > > when changes to a file 'settings' that was already tracked (and often > contains user-specific settings) should be ignored. This misguided and > short-sighted "solution" is repeated numerous times on Stackoverflow. > Not something that we should encourage. > > -- Hannes ``` ## Johannes Sixt, 2022-01-15 15:38 Subject: Re: A new feature command request `cmd_ignore` Message-ID: <9a7eac53-79fe-24f5-225a-d00d26e67259@kdbg.org> URL: https://gitlist.dev/e/9a7eac53-79fe-24f5-225a-d00d26e67259%40kdbg.org In-Reply-To: <9a3837b4-8c67-e114-e977-f6c7b729ba45@gmail.com> ``` Am 15.01.22 um 11:45 schrieb Jaydeep Das: > >> I think that is a paraphrase of the suggestion to > >    git rm --cached settings >    echo settings >> .gitignore > >> when changes to a file 'settings' that was already tracked (and often >> contains user-specific settings) should be ignored. This misguided and >> short-sighted "solution" is repeated numerous times on Stackoverflow. >> Not something that we should encourage. > > So what should be done in this scenario? And why is it a discouraged and > misguided thing? It is misguided because if you commit the removal of 'settings', others who pull/merge this change will either see their 'settings' be removed (when they did not change the file) or their pull/merge will fail with an error about a modified file being in the way (when they did modify it). It causes a whole lot of grief for others. There are different ways to address this problem. - One is to commit a 'settings.template' file that must be copied to 'settings' and is adjusted as necessary, but not `git add`ed. - Another is to have a mechanism that can include local files that carry the user-specific settings. - Yet another is to generate the final file from a tracked template and a local, untracked, file during the build process. -- Hannes ```