Hacker News Reader

Comment by rcfox | Hacker News Reader

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.

View on HN

For 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!

You can just add it in a user-level gitignore instead of ignoring it in every repo. See: ~/.config/git/ignore

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

I'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...

yes, but user level is not a repo level

Yes, 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.

You don't need to put the scratch directory in the committed gitignore file. gitignore files are recursive. So a common approach is to use a gitignore with * in the scratch directory.

This has the disadvantage though, that this user level gitignore file will not be in the repo, which means that other less careful contributors have to fix ignoribg for themselves.

And then you have a known path to script up all your repos' stuff for backup

i usually do "*ignorethis*", so a file with .ignorethis extension does not strictly have to be under a specific directory, this might save context somewhere. similar approach but yeah, a huge life saver!

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

> Now, I could extend my user-global ignore

I'd add .nvmrc and .npmrc if you work with NodeJS.

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

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

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

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

One 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

(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)

I guess your being downvoted around not being in favor of CLI is typical at HN...

You’re not wrong. I’ve used tig, a git TUI that renders very nice views of the diffs, for many years: https://jonas.github.io/tig/

Fun fact: Jonas, the creator of tig, is an ex-colleague of mine. It’s cool working with people while using dev tools they wrote!

If you are working in a team, maybe. Though you are probably better off making sure any files containing keys are already explicitly listed in .gitignore

Plus, it's not the worst idea to exercise your "whoops we leaked our secrets" procedures. You do have procedures, right?

But I'm a little worried that solo developers might follow this device. And then not notice for weeks or months, losing large amounts of git history in the best case; Or potentially massive amounts of actual work if their original development folder is gone.

It's at least easy to fix.

Not pushing a file has a much easier fix than pushing an API key. The damage is also very different.

Sure, both have failure modes but the effect of the failure is different and acting like they're the same isn't helpful to finding solutions

That's fixed by having the CI server compile the code and run tests, and having it fail the merge and publicly shame the offender in slack when that happens.

It's often said that you can't fix behavioral problems with technology, but I've found that tooling that strictly enforces rules is really useful.

> Most of the colleagues I've worked with only use "git add ." without checking first.

I mean I do too, then git status to check what went it, then unstage files that aren't supposed to be there, rewrite .gitignore to exclude them (usually), and finally commit. Tends to be faster than manually adding each file/path. Alternatively, I start out with `git add -p` (interactive) and go through that workflow.

Git becomes a lot easier to understand once you learn its "hidden" interactive flags

Like git rebase -i as well

Secrets shouldn't be plain text in project directory >:[

> Keys, npm directories and huge binaries are fixed by deleting them later on. The horror.

Keys that are deleted are not gone from the git history. They’re still in the repo.

Same with giant blobs and binaries.

That's the horror..

Genuinely curious - do you all not have a code review process, or do the reviewers just not care?

Pull requests in github are against branches, so keys and binaries are in the repo even if removed during review.

> The technique isn’t necessarily the right choice for every repository or developer, but is an alternative to explore.

I do not think it is the right choice for any repository or developer. It just seems like terrible advice.

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

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

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

Recovery from forgetting to add something is _much_ easier than recovery from adding some weird configuration file with plaintext private keys in it.

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

I usually have *secret in .gitignore and append .secret to any files with secrets.

That's cute, too bad it's a config file mandated by your boss and it has to be called "terribletool.yaml."

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

You 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 [1] https://alint.org/docs/rules/git-hygiene/git_no_denied_paths...

> 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…

The repo should define rules for the repo, no? You have to hope other contributors have a similar local gitignore?

For 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).

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

I'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.

Now walk through exactly what would happen when those lazy people follow this approach…

You see the issue right?

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

I'd make completely different assumptions

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

I do this. What's wrong with this approach and how should it be done correctly?

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

I do all of these three. I guess there's nothing wrong in this approach after all. It just boils down to "not push shitty commits"

Either you are paying attention or you are doing what the GP described in their comment. The two are mutually exclusive.

So the better alternative is for them to leave out files that should be committed?

  > people who are lazy and so just do `git add . && git commit -m ... && git push -f origin` every time.

People? Even LLMs do that

LLMs learned from people xD

That does not match my experience at all. I'm sure this did happen, but what I see from agents is obsessively checking `git status` before doing anything git related.

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

In my 12 years of software engineering I've seen 10s of times people commit junk.

orr, ~/.gitignore

Reply on news.ycombinator.com