Re: Questions, improvements

["brian m. carlson" <sandals@crustytoothpaste.net>]

[-- Attachment #1: Type: text/plain, Size: 2376 bytes --]

On 2021-10-20 at 12:25:32, BARDOT Jérôme wrote:
> 
> On 19/10/2021 23:31, Jeff King wrote:
> > I think you may have a hard time getting people to agree on what should
> > go into those rules. ;)
> 
> Yes but for certain things i think we will are most of us agree. (In
> professional context)
> 
> Temp files for Operating System, file system, text editor and IDE.

Unfortunately, there are a lot of different patterns here.  Some IDEs
use entire directories, and sometimes those patterns conflict with
common patterns used elsewhere.

For example, GitHub's recommended Visual Studio .gitignore[0] recommends
excluding directories "Bin" and "bin".  However, it is extremely common
for folks to have a "bin" directory in their dotfiles (I do, at least),
and that would cause problems.

It is generally recommended that projects try to remain reasonably
editor independent so that people can use whichever editor they prefer.
As a result, many projects don't include any editor-specific .gitignore
patterns, and rely on each individual user using their
`core.excludesfile` settings to ignore their own editor's and operating
system's files (e.g., Vim swap files).  Only editor-agnostic files, such
as .editorconfig files or files to run linting or formatting tools, are
included.

Also, when you try to pick common patterns, you end up with having to
decide what "common" means.  Should we support every editor's temporary
files, no matter how infrequently used?  Should we only support the top
N editors?  How do we decide which editors we should support?  How do we
decide which OSes we should support?  Should all patterns be case
insensitive to support the most OSes, or case sensitive to prevent false
positives?  How do we limit the rules to avoid bad performance from
giant lists of rules?  How do we resolve conflicts between these rules?

As you can see, it becomes quite sticky pretty quickly, and we're
basically bound to make somebody unhappy.  Letting each project decide
the appropriate rules for them may not please everybody, but it at least
displeases far fewer people, and it lets the people most competent to
decide those rules (the project leaders) make the decision.

[0] https://github.com/github/gitignore/blob/master/VisualStudio.gitignore
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]