This is like an infomercial contrived situation... Sure you have to update the .gitignore sometimes, but Sisyphean? Nahh. It takes 30 seconds.
.gitignore Is Inherently Sisyphean
51–60 of 68 posts
Re: .gitignore Is Inherently Sisyphean
#52I 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,…
Fossil by default ignores files and directories starting with a dot.
So, even of you explicitly add a directory, any files or directories starting with a dot inside it gets skipped.
Re: .gitignore Is Inherently Sisyphean
#53Ideally 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.
If you want to attract novice contributors, sure. This is as much give-and-take as anything else; if you want these kind of people, then you're going to have to throw a bone to these people.
Now, if you don't want contributors, or at least novice contributors that don't know to proofread their commits or ignore their own IDE files, then this actually helps you screen out the contributors you don't want to engage with early.
Re: .gitignore Is Inherently Sisyphean
#54Earlier quoted context omitted.
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/
I don't think you need to fencesit that hard. VS Code and macOS users *that don't know how to double check their commit or ignore their junk files locally will definitely cause extra burden and lower software quality. If they can't check their commits for .vscode, do you really think they tested their code properly or thought hard about the code that they wrote? If they don't know abut local git ignore files, do you think they know the language and libraries well enough? If they didn't read the Git docs, then did they read the docs that said to not use a specific function in this way?
Re: .gitignore Is Inherently Sisyphean
#55Ideally 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.
Just use core.excludesFile, once per machine.
https://git-scm.com/docs/git-config#Documentation/git-config...
Re: .gitignore Is Inherently Sisyphean
#56I 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 use gitnr[1] to add fairly comprehensive `.gitignore` files to my repos at creation time. Ultimately, it's the responsibility of each developer to determine whether or not the files they've added to their local clone really belong in source control! I've never encountered this issue, either, and I think I'd be unhappy working on a team where it was a serious problem. That said, the whitelist approach does seem kind…
In the Go world, the whitelist approach is a popular alternative to the standard gitignore, since Go projects can kind of take any structure the developer sees fit.
To me the normal approach makes equal sense. I create a file, but I'm not ready for other people to see it yet, because it's just a placeholder. So I don't add it. But another set of files are ready, and are part of one logical step of the change, so I add them specifically and commit.
Re: .gitignore Is Inherently Sisyphean
#57I 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?
Yes, I have run into that once or twice but never to the extent that I would call it "sisyphean", haha.
Re: .gitignore Is Inherently Sisyphean
#58Earlier quoted context omitted.
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
that's right but often CI systems are ephemeral or locked down so the logs get cluttered with this noise
Re: .gitignore Is Inherently Sisyphean
#59I 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 witho…
.git/info/exclude and .gitignore are processed the exact same way.
In the very first line of the description on https://git-scm.com/docs/gitignore it states "A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details."
This is a core behavior of git that has existed since creation. The gitignore is really only there to keep git status tidy and let people blindly use git add -A. Once a file is added to a repo it is never ignored until it is removed. This is why you should should rename your example .env to .env.example.
Re: .gitignore Is Inherently Sisyphean
#60Earlier quoted context omitted.
> 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
that's right but often CI systems are ephemeral or locked down so the logs get cluttered with this noise
That’s fair. They really should revert that nonsense.