I don't want to toot my own horn, but I only check in Makefile.am and configure.ac. Here's a simple example I made a while back: https://github.com/ggreer/fsevents-tools. To build it, just run autogen.sh.
For a "real" project, https://github.com/ggreer/the_silver_searcher, I have the same set-up: Makefile.am and configure.ac with no generated code in the repo. It works fine as long as you have pkg-config, and most people do. It builds and runs on Solaris, OS X, FreeBSD, and any Linux distro you like.
Although I use autotools the "right way", I'm not a fan of it at all. There are multiple levels of generated files. Configure is generated from configure.in which is generated from configure.ac. Makefile is generated from configure and Makefile.in. Makefile.in is generated from Makefile.am. There are other files in the mix as well. Config.h, config.h.in, aclocal.m4, and various symlinks to autotools (compile, depcomp, install-sh, and missing) get generated. It's insane.
There are other problems. Minor versions of autotools can behave completely differently. AM_SILENT_MAKE was removed between automake 1.10 and 1.11. Instead of printing out minimal text during a build, scripts using that macro crash. Another example: 1.9 requires AM_PROG_CC_C_O to compile anything useful but 1.10 doesn't. What's crazy is that 1.9 actually spits out an error message telling you to add AM_PROG_CC_C_O to your configure.ac. It makes no sense.
A system this complicated can't be pruned without breaking backwards compatibility. For autotools, that's not feasible. There are too many projects that would need to be fixed. The next-best solution is to use something else for new projects and let autotools fade gently into history.
