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, [email protected] 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) <[email protected]>
>> wrote:
>>
>> On May 19, 2017, at 5:06 AM, [email protected] 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
>> [email protected]
>>
>> _______________________________________________
>> devel mailing list
>> [email protected]
>> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
>
> _______________________________________________
> devel mailing list
> [email protected]
> https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
--
Jeff Squyres
[email protected]
_______________________________________________
devel mailing list
[email protected]
https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
