git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* 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

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).