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
