BUG: handle git-describe failing to find a tag - #149

Should this be the following, given that split() always returns a list of strings?

commit = output[0]

or perhaps

commit = '-'.join(output)

Yes, thanks -- I see control/_version.py has the line __commit__ = "['0ede87e']" in my test shallow clone.

On the '-'.join(output) form. I don't know if describe ever puts out a line with a single dash (I couldn't find definitive documentation), but if a tag has one or more dashes, .split will return a list with more than 3 elements (I just tested this with a fake tag to confirm it). I could replace the .split with .rsplit('-',2) to handle this case, and use '-'.join in the event that git describe outputs a line with only one dash.

I had never considered a security aspect here. I would have thought that since we're handling 'git describe' output as a string, and storing its results as a string in _make_version.py, there's not an obvious way to get code injection. (I don't know how __conda_version__.txt and __conda_buildnum__.txt are processed.) If we postulate a compromised git, wouldn't it be possible to do code injection when git clone is executed anyway?

A final point: how useful is this elaborate versioning? Why not just use '0.8.0a0+git' in setup.py until the 0.8.0 release is made? Or, alternatively, 0.8.0a0+git<commit-hash>, which is somewhat complex, but simpler than we have now.

I think that your updated changes are good.

Regarding security, the attack is still feasible with a correct git clone program if the repository itself is corrupted. However, like having a compromised git initially, this precondition is very difficult to satisfy, so I think that it is not critical to consider.

Regarding elaborate version strings, the basic argument for including the commit hash in nonrelease revisions is the existence of many users that work from repository clones rather than releases. In my experience, these users may git clone and then perform a system-wide installation, after which work proceeds from a different directory and the original clone directory may be deleted.

To include commit hashes or other data in the version string, PEP 440 defines developmental releases to facilitate this, which involves ".dev", e.g., as used in numpy.

In the case of python-control, creating a conda package involves a build number. I am not aware of a definition of this value, but at least two recommendations are:

1. number of commits from most recent tag, http://conda-test.pydata.org/docs/build.html#environment-variables-set-during-the-build-process
2. "the number of the build" (https://docs.continuum.io/docs_oss/conda/bdist_conda#build-number), which I guess implies every time conda build is used, this value should increment.

However, some projects just fix this value at 0 or 1, e.g., bison in the conda-recipes repo.

I performed the merge because changes from this PR are needed now, and we can continue discussion and possibly change the version string generation as a separate issue or pull request.