While this is a good idea, having a `.dockerignore` reduces how much Docker has to load into the build context. For projects with large histories, the `.git` directory itself can be rather large. Add to that directories that hold build artifacts, documentation, and you are unnecessarily increasing the time it takes to start the build process.

Wondering why you think this is better. Not sure the trade off of a messy dockerfile and/or adding a bunch of layers (possibly bloating the image size) is worth the trade off if the concern is just about forgetting to update the dockerignore. The same could be said about gitignore.

Not the person you replied to, but personally, I like having control over what exactly gets into the final image, and (IME) have found that devs aren't great about remembering to update .dockerignore files. Re: extra layers, if you use multi-stage builds to separate the builder and final app images, you can avoid that.

It's nice to know what files you need to build the image. Sort of like importing libraries at the top of a source code file.

I'm not sure that's always practical. Consider the average Rails or Symfony app - you'd have to include quite a few files (even if you add entire directories at a time).