Le 26/06/2015 17:47, Gerald B. Cox a écrit :
Thanks so much for taking the time to comment.
On Fri, Jun 26, 2015 at 7:44 AM, Remi Collet <Fedora(a)famillecollet.com>
> I strongly believe the "commit hash" method should be preferred as in
> the current Guidelines (and obviously not a "last solution")
> The order that a method appears doesn't denote a preference in and of
Please help me understand something. Why are you so concerned about the
use of Git Tags? I have included text which clearly states that if the
believes that re-tagging is being used, he MUST follow a specific procedure
to resolve that issue.
This is exactly what I named "last solution".
Your proposal switch the Guidelines from
"must use hash commit"
to "could use hash commit if no other solution exists,
but really you should try something else before"
When I could understand a small relax (s/must/should) but I can't agree
with such a big change.
More, I have ~100 packages which use the hash commit.
This is really a clean way. Never encounter any issue.
And it is very simple to retrieve
Ex, for packagist registered packages, "hash commit" is the reference,
see e.g. https://packagist.org/packages/phpunit/phpunit
And it is very simple to run test build (pre/post release)
Just bump the commit value (and I do it every day, often because some
upstream ask me to run a test build before release)
More, I have lot of packages which use "pecl" upstream archive where I'm
slowly moving to github/hash commit solution. Yes! instead of upstream
archive, because in some case the archive doesn't include test suite.
And because upstream archive often are a mess,
I even have to use "git snapshot" (in some case, but seems to be the new
way to exclude test from archive, using .gitattributes, damned composer
So, from my past experience, I definitively approved the current
Guidelines as the correct one.
"For a number of reasons (immutability, availability,
uniqueness), you must use the full commit revision hash
when referring to the sources."