--recurse-submodules not available in git that ships with RHEL7

[cjw296]

Unfortunately, the fix for #122 breaks check-manifest on current releases of RHEL as they still ship with git 1.8.

You get a traceback that looks like:

E             File "site-packages/check_manifest.py", line 524, in get_vcs_files
E               return canonical_file_list(vcs.get_versioned_files())
E             File "site-packages/check_manifest.py", line 401, in get_versioned_files
E               encoding=self._encoding,
E             File "site-packages/check_manifest.py", line 163, in run
E               (output + stderr).decode(encoding, 'replace'))
E           check_manifest.CommandFailed: ['git', 'ls-files', '-z', '--recurse-submodules'] failed (status 129):
E           error: unknown option `recurse-submodules'

[mgedmin]

@phijor, any thoughts?

Personally RHEL7 compatibility is not very important to me. I will gladly merge a PR fixing it, but I'm not going to work on this myself.

It may be easier to reduce the scope of the issue by not passing --recurse-submodules to git ls-files when no .gitsubmodules file exists. Then only users actually using git submodules would be affected.

For now the suggested workaround for RHEL7 (and Debian jessie, and Ubuntu 16.04 LTS) users is to downgrade to check-manifest < 0.43.

[phijor]

I'd rather have a working check-manifest that requires a "recent" git rather than having it broken in the submodules-case but working on RHEL7.

But detecting the presence of submodules via .gitmodules seems doable, as long as there are no false negatives (i.e. repositories with submodules but without .gitmodules, wouldn't be surprised if that was possible).

[mgedmin]

Released check-manifest 0.44 with a fix for this.

[mgedmin]

The fix for this caused #153, so I reverted it in check-manifest 0.48.

git versions that don't support --recurse-submodules (i.e. anything before 2.11) are no longer supported.