I tested everything I said in my email with a GitHub repo+fork and multiple clones this morning. Please feel free to test and correct me! There seem to be two possible problems:
1. Propagating the wrong tag value. Fortunately, GitHub saves us from several cases where this can happen, unless someone force pushes tags. Which nobody should do. Ever. :-) 2. Keeping the wrong tag value and analyzing history. It's hopefully unlikely that we have a "GitHub fork created when the bad tag was present" situation. It's also probably unlikely that people will need to look closely at the v1.10 branch in detail in the future, since that release series is now effectively done. More specifically: hopefully everyone does the "git tag -d ..." instructions and this becomes a moot point. > 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
