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
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, r...@open-mpi.org wrote:
>
> I would only point out that the
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
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
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 h
Hi folks
I apparently inadvertently tagged the wrong hash the other night when tagging
v1.10.7. I have corrected it, but if you updated your clone _and_ checked out
the v1.10.7 tag in the interim, you might need to manually delete the tag on
your clone and re-pull.
It’s trivial to do:
$ git t
