Also, someone asked me off-list: If I "rm -rf" my clone and re-clone, is that sufficient?
Yes, that will do the trick (i.e., you will get the new/correct tag value). Thanks for the clarification! > On May 19, 2017, at 11:25 AM, r...@open-mpi.org wrote: > > I would only point out that the panic tone of these statements appears > unwarranted based on all available documentation. I’m not convinced this > analysis is correct as it seems to contradict the documentation. > > Nevertheless, there is certainly no harm in executing the recommended steps, > and it is a good idea to do it. > > >> On May 19, 2017, at 8:03 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> >> wrote: >> >> On May 19, 2017, at 5:06 AM, r...@open-mpi.org wrote: >>> >>> $ git tag -d v1.10.7 >>> $ git pull (or whatever your favorite update command is) >> >> ************************************************************************************************* >> *** Everybody needs to do this, regardless of whether you have checked out >> the git tag or not *** >> ************************************************************************************************* >> >> SHORT VERSION >> ============= >> >> - Ralph changed the v1.10.7 tag on the ompi GitHub repo to point to the >> correct location. It's done, don't bother saying, "you shouldn't have done >> that!". It's done. Everyone **NEEDS** to update their local repos to get >> the new/correct tag. >> >> - Note that Git automatically fetches tags the *first* time they are seen; >> it doesn't matter if you've checked out that tag or not. So even if you >> haven't checked out v1.10.7, you *****NEEEEEEED***** to do the above >> procedure. >> >> - Additionally, if you have propagated the "incorrect" tag elsewhere (e.g., >> into other local repos, or your GitHub fork), you need to chase it down and >> delete / re-fetch the tags there, too. Do it now. >> >> MORE DETAIL >> =========== >> >> By default, git will fetch any new tag that it sees upstream. You don't >> have to check out that tag -- just a "git fetch" will pull down any new tags >> that it sees upstream. >> >> If the tag changes upstream, but you already have that tag, git won't fetch >> the new/changed upstream tag. Hence, you can *think* you have the right tag >> value, but you really don't. It's kinda a form of silent data corruption. >> Hence, the "git tag -d ..." instructions above -- it deletes your local tag >> and then you do another fetch, so it re-obtains the tag from upstream. >> >> The danger is if anyone pushes tags to our repos. If the pusher has the >> *old* tag, they'll could/will re-push the old tag. Fortunately, Github >> seems to disallow overwriting tags by default -- if you have the tag FOO >> value X and try to "git push --tags" when there is already a tag FOO with >> value Y upstream, it'll abort. But GitHub does allow "git push --tags >> --force", which will overwrite the upstream FOO with Y. This is a danger. >> >> Note that this doesn't apply just to release managers with access to the >> release branches -- since we allow direct pushing to master, any of us can >> "git push --tags" (and/or --force). >> >> Meaning: Git tags are just *another* reason not to --force push to the ompi >> repo. Don't ever, Ever, EVER --force push anything to the public main ompi >> repo. >> >> A secondary, lesser danger is that most people don't update tags in their >> forks. If they get the old/wrong tag in their fork, it'll likely never be >> updated. The wrong tag existed for about a week or so, so hopefully no one >> created a fork in that time (and therefore has the wrong tag). But forks >> with wrong tags aren't usually a *problem* (because who looks at tags in >> forks?), but it is weird that a fork has one value of the tag and the main >> repo has a different one. >> >> I think the main fear from all of this is the silent, unintentional >> propagation of the old / incorrect tag -- in 2 years, when Future Bob is >> looking back at the git history to try to figure out some tangled issue, >> will they have the right tag? Will Future Bob have confidence in the git >> history data? ...etc. >> >> Meaning: everyone go do the "git tag -d ..." procedure. Stop reading; go do >> it now. >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> >> _______________________________________________ >> devel mailing list >> devel@lists.open-mpi.org >> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel > > _______________________________________________ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel -- Jeff Squyres jsquy...@cisco.com _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel