logoalt Hacker News

rcfoxyesterday at 2:46 PM14 repliesview on HN

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.


Replies

electroviryesterday at 3:52 PM

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!

show 3 replies
setopttoday at 5:51 AM

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.

dietr1chyesterday at 5:27 PM

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.

show 1 reply
traviswingoyesterday at 3:54 PM

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

show 1 reply
grim_ioyesterday at 5:30 PM

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.

show 5 replies
quuxplusonetoday at 3:26 AM

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.

zelphirkaltyesterday at 8:48 PM

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.

frizlabyesterday at 7:03 PM

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

show 1 reply
aleqsyesterday at 4:06 PM

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

der_gopheryesterday at 6:18 PM

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

gruezyesterday at 2:51 PM

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

show 7 replies
LaGrangeyesterday at 3:46 PM

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

show 2 replies
ramon156yesterday at 7:38 PM

orr, ~/.gitignore