Earlier quoted context omitted.
[deleted]
What project is using .gitignore but not git?
For one thing, many AI code helpers use the contents of .gitignore as a suggestion for files to not include in their context or changes.
.gitignore Is Inherently Sisyphean
41–50 of 68 posts
Re: .gitignore Is Inherently Sisyphean
#42Re: .gitignore Is Inherently Sisyphean
#43I have never once experienced this problem. Mostly because I don't work with people who blindly commit everything without even looking once to see what's in their commit.
Interns and new hires sometimes need a quick chat about actually looking at their changes before asking for a review, but that's about it in my experience. I guess it could be a problem for a project which accepts a large number of public PRs from mostly non-technical or beginner users?
It's not a problem with PRs if you use Squash merge, the developer can make any number of changes to that PR but in the end, only the final version (in this case it doesn't include .DS_Store) will be commited. even the .DS_Store file will not be in the git index
Re: .gitignore Is Inherently Sisyphean
#44Allow /deny list, hope that helps.
This list is not really to allow permissions; it is the including and excluding list.
Re: .gitignore Is Inherently Sisyphean
#45I did not know that it can be used for whitelist (although I probably would have figured it out if I use mainly git for version control, which I don't), although I had not used .gitignore and I used "fossil add" to add the files that I wanted instead, which is also a kind of whitelist.
I did think the blacklist for this purpose was a bad idea anyways, before I saw this, so I used whitelist anyways already. (However, you can use which way you prefer, in case you do not like this, either.)
Re: .gitignore Is Inherently Sisyphean
#46I have never once experienced this problem. Mostly because I don't work with people who blindly commit everything without even looking once to see what's in their commit.
I had this issue all the time. Until I retired as a CS college professor. An accept-list is the way to go when you have lots of people making commits.
Re: .gitignore Is Inherently Sisyphean
#47I think .gitignore design is flawed. If I don't want file to be versioned, I don't want its _mention_ in VCS either.
Of course there is .git/info/exclude, but I'm not sure it's working an already cached (present on remote) files. This is another common use case git handles badly - local changelist. For example having .env file on remote with variable names only to denote structure and filling those out in local without showing these modifications in staging.
Re: .gitignore Is Inherently Sisyphean
#48Earlier quoted context omitted.
[deleted]
What project is using .gitignore but not git?
Lots of non-git tools use them. Some that come to mind are ripgrep (by default ignores .gitignore'd files), some editors (greying them out in the file selector, not searching them, etc), rustic (not backing them up), probably more.
Re: .gitignore Is Inherently Sisyphean
#49Ideally people who have .DS_Store, .vscode, etc. would put them into their own $GIT_DIR/info/exclude files and not pollute the shared .gitignore with stuff from their personal setup.
I've found that reducing the friction, as much as possible, is the only way to get people to actually contribute. Excluding things like .vscode and .DS_store, which is a common and universal "don't need that in my repo", is a trivial way to reduce the burden for everyone (the goal of software, imo), maintainer included.
> Excluding things like .vscode and .DS_store
I’m old and cranky enough to want to believe that excluding contributions from VS Code and macOS users is a trivial way to reduce the maintainer’s burden and improve software quality.
That’s completely unfair, of course, and probably false too.
edit: s/maybe/probably/
Re: .gitignore Is Inherently Sisyphean
#50This isn't a terrible way to go about things. I normally add .*/ to the gitignore. Most crap I don't want is a hidden directory. It's easy to whitelist a few bad actors, and the gitignore stays pretty short.
this really should be git's default, with a warning on git init . They decided to waste the default warning with a wrist-slap for using "master"
> They decided to waste the default warning with a wrist-slap for using "master"
I think that one can eliminate that by adding this to /etc/gitconfig, ~/.config/git/config or ~/.gitconfig as appropriate:
[init]
defaultBranch = master