* A new feature command request `cmd_ignore`
@ 2022-01-14 18:58 Jaydeep Das
2022-01-15 5:17 ` Elijah Newren
0 siblings, 1 reply; 5+ messages in thread
From: Jaydeep Das @ 2022-01-14 18:58 UTC (permalink / raw)
To: git
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: A new feature command request `cmd_ignore`
2022-01-14 18:58 A new feature command request `cmd_ignore` Jaydeep Das
@ 2022-01-15 5:17 ` Elijah Newren
2022-01-15 9:03 ` Johannes Sixt
0 siblings, 1 reply; 5+ messages in thread
From: Elijah Newren @ 2022-01-15 5:17 UTC (permalink / raw)
To: Jaydeep Das; +Cc: Git Mailing List
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: A new feature command request `cmd_ignore`
2022-01-15 5:17 ` Elijah Newren
@ 2022-01-15 9:03 ` Johannes Sixt
2022-01-15 10:45 ` Jaydeep Das
0 siblings, 1 reply; 5+ messages in thread
From: Johannes Sixt @ 2022-01-15 9:03 UTC (permalink / raw)
To: Elijah Newren; +Cc: Git Mailing List, Jaydeep Das
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: A new feature command request `cmd_ignore`
2022-01-15 9:03 ` Johannes Sixt
@ 2022-01-15 10:45 ` Jaydeep Das
2022-01-15 15:38 ` Johannes Sixt
0 siblings, 1 reply; 5+ messages in thread
From: Jaydeep Das @ 2022-01-15 10:45 UTC (permalink / raw)
Cc: Git Mailing List
> 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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: A new feature command request `cmd_ignore`
2022-01-15 10:45 ` Jaydeep Das
@ 2022-01-15 15:38 ` Johannes Sixt
0 siblings, 0 replies; 5+ messages in thread
From: Johannes Sixt @ 2022-01-15 15:38 UTC (permalink / raw)
To: Jaydeep Das; +Cc: Git Mailing List
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-01-15 15:38 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-14 18:58 A new feature command request `cmd_ignore` Jaydeep Das
2022-01-15 5:17 ` Elijah Newren
2022-01-15 9:03 ` Johannes Sixt
2022-01-15 10:45 ` Jaydeep Das
2022-01-15 15:38 ` Johannes Sixt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.