4 ms·
This seems like bad advice. I've very rarely committed extra files by accident, but I would 100% forget to unignore files I meant to commit. If you're doing an
by rcfox 28d ago
This seems like bad advice. I've very rarely committed extra files by accident, but I would 100% forget to unignore files I meant to commit.
If you're doing an initial setup step to gitignore everything, why not just do an initial setup step to gitignore the usual files? Make a template that you copy into all of your repos.
- gruez 28d ago>This seems like bad advice. I've very rarely committed extra files by accident, [...] You clearly haven't seen the people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time.
- cush 28d agoNow walk through exactly what would happen when those lazy people follow this approach… You see the issue right?
- cortesoft 28d agoI think the idea is that missing files will immediately cause issues (tests will fail, etc), so CI should catch this immediately. Adding extra, sensitive, files would not cause test failures, and even if they do (via secret scanners, etc), it is too late at that point because they will have already been shared upstream. I am not sure the juice is worth the squeeze here, but it has some logic to it.
- cush 28d agoI'd make completely different assumptions
- rcfox 28d agoI'm not convinced people acting on muscle memory would remember to unignore the files either. They're going to lose work or have giant "oops, I forgot to commit these files" commits.
- JimDabell 28d ago> You clearly haven't seen the people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time. I’ve worked with and managed plenty of people like that and those are the people I least want doing something like this. Seeing the flotsam and jetsam of .DS_Store etc. are an early warning sign they aren’t paying any attention to what they push and the sooner that gets caught and addressed the better.
- efilife 28d agoI do this. What's wrong with this approach and how should it be done correctly?
- JimDabell 28d agoPay attention to what you are staging. Generally this means `git add -p` or similar. Pay attention to what you are committing. Generally this means looking at what you have staged before writing your commit log message. Pay attention to what is in your pull request. Generally this means looking at your commits / draft pull request before you ask for code review. If anybody other than you sees crap in your pull request that should obviously have been ignored, it means you have failed to pay attention to what you are doing three separate times.
- jeremyjh 28d agoSo the better alternative is for them to leave out files that should be committed?
- godelski 28d ago> people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time. People? Even LLMs do that
- ozim 28d agoI do that for my personal projects. Doing that on projects where I collaborate I would equate to pissing in public. That is also why pull requests are such a great idea in general, because GIT allows one to piss in his own garden as much as they want. Even if I could piss in my own branch I never do so when working on a project with other people. I don't piss around my home obviously in case someone didn't get the metaphor.
- LaGrange 28d agoRecovery from forgetting to add something is _much_ easier than recovery from adding some weird configuration file with plaintext private keys in it.
- SmasherEpilepti 28d agoIt depends. I've lost hours of work after wiping and recreating a repo that had accidentally gitignored a file I was working on, and I didn't notice until too late.
- wafflemaker 28d agoI usually have *secret in .gitignore and append .secret to any files with secrets.
- LaGrange 28d agoThat's cute, too bad it's a config file mandated by your boss and it has to be called "terribletool.yaml."
- wafflemaker 28d agoNever worked professionally in programming and I was told that home projects is like child's play. Especially the humility it requires - remember being mad when my younger brother joined my Factorio game and changed smelters setup. To an actually better one - one thing when people correct your technical solutions, double so bad when they are actually right.
- electrovir 28d agoFor many years I've have a git-ignored ".not-committed" folder in all of my repos for throwing extra anything into. It's been a huge life saver!
- Zambyte 28d agoYou can just add it in a user-level gitignore instead of ignoring it in every repo. See: ~/.config/git/ignore
- saghm 28d agoI only realized very recently that being able to specify .gitignore files in any part of a repo can be combined with wildcards to just put `.gitignore` with `*` in a arbitrary directories to make them get ignored without needing to modify any wider configuration.
- zzril 28d agoI'm doing that all the time. Starting with a .vim directory that contains vim-specific files, such as scripts / build commands to be run on certain key combinations, to ".misc" / ".scratch" / ".notes" / ".api-keys" directories... I wouldn't want to list them all in my global .gitignore because I'd certainly forget half of the names I tend to give to these...
- der_gopher 28d agoyes, but user level is not a repo level
- sReinwald 28d agoYes, but this is exactly the sort of thing that should be a user-level configuration. A personal scratch directory has nothing to do with the repository itself and doesn’t belong in a repo’s .gitignore. If it's only needed for one particular checkout, .git/info/exclude is the other obvious option.
- traviswingo 28d ago> The technique isn’t necessarily the right choice for every repository or developer, but is an alternative to explore.
- jeltz 28d agoI do not think it is the right choice for any repository or developer. It just seems like terrible advice.
- aleqs 28d agoYou can also use something like alint [0][1] to define and enforce rules about files/globs that should or shouldn't be committed, among other things. You can configure it to run as a pre-commit hook or in CI. (disclaimer - this is my own tool) [0] https://github.com/asamarts/alint https://github.com/asamarts/alint [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths/ https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...
- dietr1ch 28d agoI have a small user-global gitignore that most of the job for me, ```.gitignore # Ignores ## Unix hidden files .* ## Temporary files and backups *~ *.swp *.bak # Exceptions !.ignore !.gitignore ``` But I tend to copy it over and extend it as I go, and there's well-known reference gitignore files to skim for if you have anxiety around any particular language/editor/tool. Now, I could extend my user-global ignore, but there's no project where I want the state of the repo to be wrong, but my local state saving me unknowingly, as I know it'll bite others.
- mschuster91 28d ago> Now, I could extend my user-global ignore I'd add .nvmrc and .npmrc if you work with NodeJS.
- dietr1ch 28d agobut if I add that to my user-global config instead of the projects I'm working with, I'd be making the deliberate choice of fixing things only for me and not anyone else for pretty much the exact same cost. I think rules for your personal tools, like editor-specific ignores belong to your user-level config, but anything around the project's tools and artifacts belongs in the project's gitignore.
- grim_io 28d agoMost of the colleagues I've worked with only use "git add ." without checking first. Keys, npm directories and huge binaries are fixed by deleting them later on. The horror.
- rcv 28d agoGenuinely curious - do you all not have a code review process, or do the reviewers just not care?
- hedora 28d agoPull requests in github are against branches, so keys and binaries are in the repo even if removed during review.
- kryptiskt 28d agoThe problem is that those developers are also going to forget to update the ignore-by-default .gitignore to allow files, so there will be missing files. And they won't see any problems, because it works on their machine.
- yurishimo 28d agoIn my opinion this will pretty quickly solve itself though. Accidentally committing keys to the repo potentially ruins your entire week. With a default disallow all list, you might have one bad deploy oopsie and then commit the files.
- ozim 28d agoOne problem I see all the time is that people are not using proper tools. Yeah command line is cool and all but I do believe most of the developers should be using UI tooling where staging area is showing nice diffs. Built in GIT handling in IDE usually is better than command line but also usually worse than dedicated tool like GitExtensions or SourceTree which are free and are super convenient for staging. People don't know they don't have to stage whole files but they can stage hunks, well in command line it is too much hassle for me but in GUI tools it is no brainer. I recommend looking here: https://git-scm.com/tools/guis https://git-scm.com/tools/guis (it might be that you will be waaay cooler using GUI tool because you will be able to fix things others can't ... saying from my experience)
- der_gopher 28d agoIn my 12 years of software engineering I've seen 10s of times people commit junk.
- frizlab 28d ago> why not just do an initial setup step to gitignore the usual files? Or even better, have a proper global gitignore file on your computer…
- jayd16 28d agoThe repo should define rules for the repo, no? You have to hope other contributors have a similar local gitignore?
- frizlab 28d agoFor files like `.DS_Store`, technically yes. Usually the people do not have a proper global gitignore, so we put these files in the gitignore of the repo, but it’s not repo-related, it’s OS-related… Same goes for editor files. The editor is something user-related, not project related (except e.g. for iOS development where the IDE is kind of more or less imposed).
- ramon156 28d agoorr, ~/.gitignore
- deleted 28d ago[deleted]
- zelphirkalt 28d agoIt is easy to do a rebase, adding more files to an already pushed commit. It is impossible to be sure, that no one has read already leaked secrets. Err on the side of caution.
- quuxplusone 28d agoI dunno, I've never done what TFA suggests, but it makes sense to me. The idea isn't that your new foo.go file would be ignored by default; it's that your Go project's repo's .gitignore file would start with * and then !*.go , so that your new foo.go file would show up as untracked-and-unignored but your new foo.go.sav~ and .DS_Store and .foobarrc files would not. Maybe that's more ergonomic than forcing all users to learn about ~/.gitignore or manually adding .DS_Store *.sav~ et cetera into your Go project's repo's .gitignore.
- setopt 28d agoI also don’t commit files by accident. Just don’t `git add *` as some people do, and check `git status` before committing, and then you’re good.