pdf.js version not set correctly for builds of downloaded sources (non-git repositories)

[qwer1304]

I finally (I hope) figured out why the version number of pdf.js Chrome extensions built by me didn't have the correct version.
I downloaded the 2.0.550 archive from the releases pages, set up everything as should (npm, gulp, etc) and then tried to build a Chrome extension.
The build is successfull, but the resulting extension has 2.0.0 version.
The problem is that gulpfile.js assumes it's in a git repository to determine the build number (see line 426 and on), but it's not in this case (git gives fatal: Not a git repository (or any of the parent directories): .git)
This wouldn't happen if the directory were obtained using git clone ... in which case it would be a proper git repository.

[timvandermeij]

Indeed, that may well be the case. I don't really think there is anything we can do about that though because the version number is determined by the commits. Only a different versioning scheme could help, but for now that's not really considered.

[qwer1304]

You could at least put a comment / warning in the README.

[Snuffleupagus]

Perhaps it would make more sense to just error out, rather than generating a fake buildnumber?

pdf.js/gulpfile.js

Lines 431 to 434 in 34594a5

	if (!err) {
	// Build number is the number of commits since base version
	buildNumber = stdout ? stdout.match(/\n/g).length : 0;
	}

[timvandermeij]

I don't really see this as a problem, but if someone wants to contribute a patch for that I'm fine with it. Marking as a good beginner bug.