I am not as negative as Ed about using it because in my experience the code does not use a superficial view of git alone. The Eclipse CDT project and other Eclipse projects use it, including AFIAK the Eclipse Platform project. While it does use git history, it actually compares the contents of the class files and other files in the jars*. So for example, if your code inlines a constant that changes in some dependency, the git would show no difference, but the class file will be different and therefore a difference to baseline will be reported.
One of the most useful effects of the reproducible build qualifiers is that it prevents a project from releasing the same jar with only build qualifier being different.
On Mon., Feb. 17, 2020, 15:01 Ed Willink, <ed@xxxxxxxxxxxxx> wrote:
Hi
On a good day, the reproducible qualifiers avoid you churning a
new set of unchanged artefacts every build, thereby saving on
distribution bandwidth.
However that good day is totally depend on the fairies, since an
unsound superficial view of GIT dependencies rather than a true
has-it-changed-test is used.