search

openlayers / ol2

OpenLayers v2 - deprecated!
Other
1.47k stars 771 forks source link

Include git commit id in OpenLayers minified js #463

Open fbuchinger opened 12 years ago

fbuchinger commented 12 years ago

In some more experimental projects I'm developing against the master branch of Openlayers. For performance reasons I also minify my master version from time to time. Unfortunately there is no reference between the minified version and the git commit id it was built from. This makes it difficult to track down errors/changing behaviour introduced by a certain openlayers commit.

It would be nice if the OpenLayers build script could include this information in the minified js.

probins commented 12 years ago

what I do is include the output from git describe --tags as a comment at the front of the file.

I have also thought of changing the build script to set this in OpenLayers.VERSION_NUMBER, which isn't very useful at the moment.

fbuchinger commented 12 years ago

I like your idea of "enhancing" OpenLayers.VERSION_NUMBER with the corresponding git tag. Maybe this could be added to the OpenLayers build script?

The tag info could be obtained either by calling the git executable or by using the dulwich library (https://launchpad.net/dulwich). The second option seems quite an overkill to me.

probins commented 12 years ago

ideally, it would be updated on every commit rather than in the build script; then it would always be up-to-date on master (and any other branch). Don't know how you would do that, though.

elemoine commented 12 years ago

FYI Git does not natively support "keyword substitution". See http://www.gelato.unsw.edu.au/archives/git/0610/28891.html. That does not mean we should not something about it.

mprins commented 12 years ago

git describe as part of a build comes close to what you want. However git, being distributed, makes this impossible to do reliably. There is no central location where revisionnumbers are stored like there is in subversion, each cloned repository generates it own revision numbers (SHA1 hashes) for every commit making this only useful for fresh clones. When people start using git rebase or git reflog unexpected things may happen to the revision history...

elemoine commented 12 years ago

I don't think we should ever rewrite the master branch's history anyway. Rewriting history that's shared among multiple developers would cause problem to these developers.

probins commented 12 years ago

I don't think we should ever rewrite the master branch's history anyway

yes, I think that should be a no-no

And, of course, doing anything git-ish in the build assumes that git is installed and that the build is being run on a git repo, which may well not be the case for those who are building from a download.