threads / discuss / 57247

A new feature command request `cmd_ignore`

Subject: A new feature command request `cmd_ignore`

## tl;dr

5 messages between Jan 14, 2022 and Jan 15, 2022.

replies: 4people: 3as markdown or json

Jaydeep Das· Jan 14, 2022, 18:58 UTC · lore

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· Jan 15, 2022, 05:17 UTC · re: Jaydeep Das · lore

Re: A new feature command request `cmd_ignore`

On Fri, Jan 14, 2022 at 3:03 PM Jaydeep Das <jaydeepjd.8914@gmail.com> 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· Jan 15, 2022, 09:03 UTC · re: Elijah Newren · lore

Re: A new feature command request `cmd_ignore`

Am 15.01.22 um 06:17 schrieb Elijah Newren:
Show 6 quoted lines
> On Fri, Jan 14, 2022 at 3:03 PM Jaydeep Das <jaydeepjd.8914@gmail.com> 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· Jan 15, 2022, 10:45 UTC · re: Johannes Sixt · lore

Re: A new feature command request `cmd_ignore`

> 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:
Show 17 quoted lines
> Am 15.01.22 um 06:17 schrieb Elijah Newren:
>> On Fri, Jan 14, 2022 at 3:03 PM Jaydeep Das <jaydeepjd.8914@gmail.com> 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· Jan 15, 2022, 15:38 UTC · re: Jaydeep Das · lore

Re: A new feature command request `cmd_ignore`

Am 15.01.22 um 11:45 schrieb Jaydeep Das:
Show 13 quoted lines
> 
>> 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

← back to recent threads