Currently Nitpick stores the VCS used inside the repository configuration. This works fine as long as you only use one VCS with the repository. However there are situations, such as the Nitpick source itself, where multiple VCSes could be used.
For example, primary of the Nitpick development happens in SVN, but there is a Git mirror which users and other developers use. It's also possible that somebody could download a tarball and want to use Nitpick on that bug repository.
It would be convenient if Nitpick could truly detect the VCS instead. Perhaps this might be best accomplished by adding a new VCS type "detect" which searches up the tree from .nitpick for the various markers of particular VCSes such as .git, .svn, .hg and the like. It would then still be possible to override the choice if detection were difficult to implemented, such as the case for Perforce, or the software has a complex configuration which confused the detection.
Currently Nitpick stores the VCS used inside the repository configuration. This works fine as long as you only use one VCS with the repository. However there are situations, such as the Nitpick source itself, where multiple VCSes could be used. For example, primary of the Nitpick development happens in SVN, but there is a Git mirror which users and other developers use. It's also possible that somebody could download a tarball and want to use Nitpick on that bug repository.
Date: 2017-01-25 15:25:07
User: travisb
It would be convenient if Nitpick could truly detect the VCS instead. Perhaps this might be best accomplished by adding a new VCS type "detect" which searches up the tree from .nitpick for the various markers of particular VCSes such as .git, .svn, .hg and the like. It would then still be possible to override the choice if detection were difficult to implemented, such as the case for Perforce, or the software has a complex configuration which confused the detection.