Re: [PATCH 03/11 RFC] gitignore: Add/Generalize entries

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.09.2020 23:48, Elliott Mitchell wrote:
> On Thu, Sep 24, 2020 at 05:44:09PM +0200, Jan Beulich wrote:
>> On 02.09.2020 03:08, Elliott Mitchell wrote:
>>> @@ -33,12 +38,12 @@ cscope.po.out
>>>  .vscode
>>>  
>>>  dist
>>> -stubdom/*.tar.gz
>>>  
>>>  autom4te.cache/
>>>  config.log
>>>  config.status
>>>  config.cache
>>> +config.h
>>>  config/Toplevel.mk
>>>  config/Paths.mk
>>
>> While in userland config.h may indeed be a typically generated file,
>> there are three source files by this name under xen/. Patch 6 also
>> doesn't look to override this in any way for xen/. I think this wants
>> to move a level down, into tools/ and wherever else it may be
>> applicable.
> 
> Another possibility is Git isn't as aggressive with enforcing ignores as
> some other version control software is.  A file which matches a
> .gitignore pattern will not show up under "Untracked files" in
> `git status`; however, /modifying/ a file which is already under control,
> but matches an ignore pattern *will* cause it to show up under
> "Changes not staged for commit".  Git will also allow you to use
> `git add -f` on a file which matches an ignore pattern.
> 
> There are already a few files in Git which have targetted matches pointed
> at them, yet are still present.  Perhaps these were added by mistaken use
> of `add -f`, perhaps they were deliberately added and the author missed
> removing the .gitignore entry.
> 
> As such perhaps the generalized "config.h" pattern is appropriate and
> move towards removing the few examples which currently exist?

I don't think so, no - new ports will similarly have asm-<arch>/config.h,
and there shouldn't be a requirement to "git add -f" them at that point.
The role of such named files really is too different to have such a top
level entry imo.

Jan