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
