I also tested with my multiple clones before committing the new tag, following the Git documentation. In no case did I encounter a problem.
I agree that someone force pushing tags will cause a problem, but (as has been noted multiple times now) we don’t allow that in our repo as it would -always- cause a problem, regardless of this kerfluffle. So this is a non-issue I also agree that following the instructions will resolve any future issues. There are other ways of also getting there, but those are simple enough, and (per your other note) an “rm -rf” is the ultimate solution, albeit unnecessarily dramatic. And I also agree with Brian that the documentation may not mirror what people see in practice. The problem is that Git is so atomistic that you can create as big a mudpie as you want - sadly, people don’t bother to read nor follow the docs, and so you can get weird behavior and attribute it to Git. Anyway, enough - far more electrons burned on this than it is worth. > On May 19, 2017, at 10:29 AM, Jeff Squyres (jsquyres) <jsquy...@cisco.com> > wrote: > > 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 _______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
