A new feature command request `cmd_ignore`

A new feature command request `cmd_ignore`

[Jaydeep Das]

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.

Re: A new feature command request `cmd_ignore`

[Elijah Newren]

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.

Re: A new feature command request `cmd_ignore`

[Johannes Sixt]

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

Re: A new feature command request `cmd_ignore`

[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?


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 <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

Re: A new feature command request `cmd_ignore`

[Johannes Sixt]

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