When is this file created?

Other files to consider: .build-*.log and results_*, which are created by mockbuild.
Also clog would be nice.

When is this file created?
just for example. No functional reason.

Other files to consider: .build-.log and results_, which are created by mockbuild.
Also clog would be nice.

added

Suggest: more short version: git_excludes or []

I'm thinking if rpkg.conf is a good place to read these patterns from the point of view of extensible purpose for downstream package tools like fedpkg. Let's use fedpkg as an example in the discussion below.

When running fedpkg, rpkg code reads fedpkg.conf instead of rpkg.conf, so git_excludes has to be duplicated in fedpkg.conf. On the other hand, fedpkg also has some other patterns that could be ignored, for example bodhi.template. To extend the list, fedpkg has to duplicate the list and then add new ones. Once there is any new pattern to be ignored, the duplicaiton must happen again. This may not be a good thing.

The patterns listed in git_excludes are generated or required by the code logic in whatever rpkg or fedpkg, they are not configurable actually. I think defining and extending the pattern list through the pyrpkg.Commands class inheritance would be a better way, e.g.

class Command(object):
    git_exclude_patterns = ['i386/', 'noarch/', 'result_*', ...]
# in fedpkg
class Commands(pyrpkg.Commands):
    pyrpkg.Commands.git_exclude_patterns += ['bodhi.template']

@cqi, maybe I do not understand the whole picture. Do we have a hierarchy/duplicate problem? rpkg configuration here is a fake and serves just for example and reminder (I can delete if needed). Real patterns should be defined directly in rhpkg and fedpkg configuration files. So another PR have to be opened for this in fedpkg just to modify configuration file.

Real patterns should be defined directly in rhpkg and fedpkg configuration files. So another PR have to be opened for this in fedpkg just to modify configuration file.

Will both rhpkg and fedpkg have same git_excludes list as the one added to rpkg.conf? And what about rpkg-tool rfpkg, centpkg, rpkg-client or other package tools built on top of rpkg?

If you intend to allow downstream package tool developers or user him/herself to select which directories and files generated by rpkg should be ignore, not all by default, it makes sense to read the list from config file.

I think we are on the same thought. rpkg processes patterns from rhpkg/fedpkg (or other) config.
Config in this PR serves as an example. I removed its changes not to confuse anybody.
In parallel, I will open PR for fedpkg to present this.

This return seems not needed.

One minor nitpick aside, this looks good to me.