On Tue, Nov 28, 2017 at 7:30 PM, Stanislav Malyshev <smalys...@gmail.com> wrote: >> If there's a mistake that needs to be fixed and that's detected within >> these two days, a re-tag needs to happen. If the old tag is deleted and a >> new modified tag is published, all cloned Git repositories that already >> received the old tag will keep the old tag and never receive the new tag >> unless the old tag is manually removed first. That's problematic. > > That's not how git is supposed to work? If you syncronize the repo you > should get the new tag. If you cloned repo once and never update then of > course you don't get new tag, but you also don't get the fix... > Erm, actually no, it's not how git is supposed to work.
If you have an up to date checkout of php-src/master right now, it contains the php-7.2.0 tag. If Remi adds more commits (to fix something) and moves that tag to the new head of the PHP-7.2.0 branch and pushes it, then anyone who HADN'T YET synced php-src/master since this morning will get the new tag fine, but you never will (not with a normal `git pull`, anyway). This is because git will not change tags unless you explicitly tell it it's okay to. Moving git tags after they've been pushed to a remote (shared) repo is as much a sin as force pushing. It shouldn't be done. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
