Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.gitignore Is Inherently Sisyphean

rgbcu.be

Post reply on HN
Print view View original

21–30 of 68 posts

Re: .gitignore Is Inherently Sisyphean

#22

Post by nomel »

edflsafoiewq wrote: post #10

Ideally 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.

Re: .gitignore Is Inherently Sisyphean

#23

Post by dogleash »

bravetraveler wrote: post #11

Common pattern/solution, not a common problem. Feels equal-if-not-more Sisyphean. Also: "Oh no, my collaborative maintenance requires both collaboration and maintenance" Don't accept people playing with shotgun commits; there, problem(s) solved.

> "Oh no, my collaborative maintenance requires both collaboration and maintenance"

chef's kiss This is replacing one of the memes on my whiteboard rn

Re: .gitignore Is Inherently Sisyphean

#24

Post by sneak »

accoil wrote: post #5

I think people should be responsible for the litter of their own tools. If their commits have include any litter it should be rejected as they clearly aren't paying attention. The local gitignore is for project specific files.

The fact that toil can be pushed off onto other people (the pushing and feedback and re-review also being additional time and effort) doesn’t change the fact that it’s toil and it’s stupid and wasteful.

Re: .gitignore Is Inherently Sisyphean

#25

Post by Baarsgaard »

FrenchyJiby wrote: post #8
davydm wrote: post #2

Cool post. I highly suggest using templates from https://github.com/github/gitignore for your project as they tend to include a lot of files commonly found in them - eg .idea folders and so on.

Yes-anding this to say: For per-user gitignore, one can set the following config in ~/.gitconfig: # System-wide gitignore file # To avoid in-repo repetition for system-specifc garbage files [core] excludesfile = ~/.config/git/gitignore Then your file at ~/.config/git/gitignore can be a normal format, and not need to be stored in repo. Perfect for system files (.DS_Store...) or editor swap files etc.

Git will per default read ~/.config/git/ignore No need to configure it :)

Re: .gitignore Is Inherently Sisyphean

#26

Post by tom_ »

pigbearpig wrote: post #15

Interesting. Makes sense for open source. In the workplace for those using common IDEs things like .vscode or .idea can definitely help with consistency or shared project setup. Each has docs which mention which files should or shouldn't be committed. Personally, I just use gitignore.io to generate the file based on my company's tooling and call it good enough.

That's what I've always seen done with git or Perforce. The initial set of all likely IDE-related files is known (just talk to the people you work with...), so you just add all of them to the ignore list (of whatever kind) and off you go. Then over time, additional entries might get added, as new platforms become supported and/or new team members join who use other IDEs. And the easiest thing is to add them to the list, because if one person is using this or that tool then there's a fair chance that somebody else will be using it in future too.

One way of thinking about this is to note that there are an awful lot of these tools, and so each person should look after their own shit rather than fucking it up for everybody else. Another is to note that the number of these tools is finite, and team members won't be using all of them, and so over time the centralized ignore file will tend towards a useful degree of completeness.

Re: .gitignore Is Inherently Sisyphean

#29

Post by elijahwright_ »

there's a good reason why this isn't done this way. Git is very open ended but there are .gitignore templates out there. ideally anyone submitting a pull request should be looking at what they're adding. but the real issue here is this:

> Luckily, you realize that you can turn the blacklist of files (the gitignore) into a whitelist, by just ignoring everything and manually un-ignoring desired files.

this will not work and tbh it's fitting a square peg in a round hole. it technically might fit if you shave off the square enough but large repos don't do this, they use a round peg: https://github.com/github/gitignore

Post reply on HN