Pointing dependency to specific commit with only numbers in it fails

[missingdays]

Output of bower -v && npm -v && node -v:

1.7.9
2.14.7
v4.2.1

Steps to reproduce the issue:

1. Have commit that has hash with the first several number-only characters, for example "70041869d.."
2. Add dependency to bower json as "project-name": "repository-link.git#70041869"
3. bower install

Describe the results you received:
I expected it to find commit with hash starting with 70041869 and download dependency from it

Describe the results you expected:
Bower told me

bower c3#70041869         ENORESTARGET No tag found that was able to satisfy 70041869

and stopped installing

Additional information:
I understand that this feature that is rarely used, and commit hashes almost always have some alphabetic charactes at the beggining, but still, this is a problem that might occur unexpectedly.

[benmann]

Is there a concrete example you are referring to and can share?

[missingdays]

@benmann let's take d3 for example
Say, this is commit I want to install - d3/d3@8777757
I check it using git log --abbrev-commit or just copy hash tag from GitHub. I get "8777757".
So

bower install d3#8777757

results in error

bower d3#8777757            not-cached https://github.com/mbostock-bower/d3-bower.git#8777757
bower d3#8777757               resolve https://github.com/mbostock-bower/d3-bower.git#8777757
bower d3#8777757          ENORESTARGET No tag found that was able to satisfy 8777757

Additional error details:
Available versions in https://github.com/mbostock-bower/d3-bower.git: 4.1.1, 4.1.0, 4.0.0, 3.5.17, 3.5.16, 3.5.15, 3.5.14, 3.5.13, 3.5.12, 3.5.11, 3.5.10, 3.5.9, 3.5.8, 3.5.7, 3.5.6, 3.5.5, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5.0, 3.4.13, 3.4.12, 3.4.11, 3.4.10, 3.4.9, 3.4.8, 3.4.6, 3.4.5, 3.4.4, 3.4.3, 3.4.2, 3.4.1, 3.4.0, 3.3.13, 3.3.12, 3.3.11, 3.3.10, 3.3.9, 3.3.8, 3.3.7, 3.3.6, 3.3.5, 3.3.4, 3.3.3, 3.3.2, 3.3.1, 3.3.0, 3.2.8, 3.2.7, 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0, 3.1.10, 3.1.9, 3.1.8, 3.1.7, 3.1.6, 3.1.5, 3.1.4, 3.1.3, 3.1.2, 3.1.1, 3.1.0, 3.0.8, 3.0.7, 3.0.6, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0.0, 2.10.3, 2.10.2, 2.10.1, 2.10.0, 2.9.7, 2.9.6, 2.9.5, 2.9.4, 2.9.3, 2.9.2, 2.9.1, 2.9.0, 2.8.1, 2.8.0, 2.7.5, 2.7.4, 2.7.3, 2.7.2, 2.7.1, 2.7.0, 2.6.1, 2.6.0, 2.5.2, 2.5.1, 2.5.0, 2.4.6, 2.4.5, 2.4.4, 2.4.3, 2.4.2, 2.4.1, 2.4.0, 2.3.4, 2.3.3, 2.3.2, 2.3.1, 2.3.0, 2.2.1, 2.2.0, 2.1.3, 2.1.2, 2.1.1, 2.1.0, 2.0.4, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 1.29.7, 1.29.6, 1.29.5, 1.29.4, 1.29.3, 1.29.2, 1.29.1, 1.29.0, 1.28.1, 1.28.0, 1.27.2, 1.27.1, 1.27.0, 1.26.0, 1.25.0, 1.24.1, 1.24.0, 1.23.0, 1.22.1, 1.22.0, 1.21.0, 1.20.3, 1.20.2, 1.20.1, 1.20.0, 1.19.1, 1.19.0, 1.18.0, 1.17.1, 1.17.0, 1.16.0, 1.15.1, 1.15.0, 1.14.2, 1.14.1, 1.14.0, 1.13.4, 1.13.3, 1.13.2, 1.13.1, 1.13.0, 1.12.0, 1.11.1, 1.11.0, 1.10.1, 1.10.0, 1.9.1, 1.9.0, 1.8.5, 1.8.4, 1.8.3, 1.8.2, 1.8.1, 1.8.0, 1.7.0, 1.6.1, 1.6.0, 1.5.3, 1.5.2, 1.5.1, 1.5.0, 1.4.0, 1.3.0, 1.2.1, 1.2.0, 1.1.0, 1.0.3, 1.0.2, 1.0.1, 1.0.0

I understand that this is specific bug, and it can be fixed by copying more characters from commit hash that is provided. But it would be cool if bower could understand that probably there are no versions higher than, say, 1 million, and would treat it as a commit hash.

[sheerun]

Until someone decides to make version by the timestamp, like 20160602 :(

[missingdays]

@sheerun Yes, you are totally right. And you can't check if such version exists, and if it doesn't, check for such commit. In this case, if somebody makes mistake and writes 20160601 instead of 20160602, it wouldn't be reliable to check commit that starts with 20160601, as it could exists.
So, I guess, the only solution is to use extended commit hashes.