FYI, all subsequent expected rewinds have occurred. The mirroring process has
been modified to reduce the risk of an accidental rewind in the future.
Several (correct) tags have been added and several (incorrect) tags have been
deleted.
Going forward, we will also add a .mailmap file to the repository to perform a
few minor name corrections and add proper emails to the commit history. This
should allow us to avoid name-related rewinds. I'll send a separate email/RFC
about the email addresses.
-Dave
On Sep 23, 2013, at 8:31 AM, David Goodell (dgoodell)
wrote:
> A clarification for those on the devel@ list who were not on our private
> email thread about these issues: "issue (F)" is the "v1.X-series" tag issue.
> That is, the second rewind has not yet happened.
>
> -Dave
>
> On Sep 22, 2013, at 3:33 AM, Eugene Voronov wrote:
>
>> Hi All,
>> I've finished with dynamic generation of authors list direct from SVN, thus
>> feature provide solution resolve issues of mirroring from svn2git.
>>
>> Last issue (F) I'll try solve in next few days.
>>
>>
>>
>>
>> -Original Message-
>> From: David Goodell (dgoodell) [mailto:dgood...@cisco.com]
>> Sent: Friday, September 20, 2013 7:27 PM
>> To: Open MPI Developers
>> Cc: Eugene Voronov; Mike Dubman
>> Subject: OMPI Git mirror history: incorrect history & rewinding
>>
>> Short Version:
>>
>> The OMPI GitHub mirror of the OMPI SVN history currently contains some bad
>> history, specifically related to the version tags. Prior to roughly
>> September 16th, this repository also contained several other bits of bad
>> information/history. The git history was *rewound* some time around the
>> 16th, which could cause problems for developers who are using it to
>> construct patches for our SVN repository. We expect the history to be
>> rewound again once at some point in the (hopefully) near future, which will
>> have a similar effect.
>>
>> Users of the git mirror may need to perform some unconventional steps to
>> recover from the upstream rewind in some cases. If you are not currently
>> experiencing any trouble with the mirror you may wish to wait until the
>> second rewind occurs in the near future.
>>
>>
>> More Detail:
>>
>> Though OMPI uses SVN as the canonical version control system (VCS), many
>> developers use Mercurial (hg) or Git repositories for feature development
>> and collaboration before bringing those changes back to SVN. To this end,
>> there are two helpful mirrors hosted on bitbucket and GitHub respectively:
>>
>> https://bitbucket.org/ompiteam/ompi-svn-mirror
>> https://github.com/open-mpi/ompi-svn-mirror
>>
>> The Git mirror is maintained by Mellanox and has been extremely helpful so
>> far. However, in July it became clear that some of the history in the
>> mirror was incorrect. Specifically:
>>
>> 1) Several commits had been squashed into a single commit, losing some
>> history (eb0b490+7fc1da3+36d7b2c+482041f --> 616629d). However, the tree
>> (Git-speak for file contents) at each commit always matched the
>> corresponding commit message.
>>
>> 2) Some author names and user IDs were incorrect in the history. The
>> severity of this is low, since they were all typo-level inaccuracies, not
>> arbitrarily swapped names.
>>
>> 3) Most of the release tags are incorrect. The mirror has tags of the form
>> "v1.X-series" (where "X" is a valid number) instead of "v1.6.2". These
>> "-series" tags then contain directories for each release within that series
>> instead of the expected source tree.
>>
>> Eugene V. at Mellanox recently (~2013-09-16) updated the mirror to address
>> issues (1) and (2). Issue (3) remains outstanding, necessitating a future
>> update at some as-yet unspecified time. Unfortunately, the act of updating
>> the repository to resolve these issues causes entirely new commit ID hashes
>> to be created, resulting in a "rewind" of all of the Git branches and tags
>> in the mirror. Most git users have not encountered this case and may
>> experience difficulty coping with it.
>>
>> If you encounter trouble with these recent repository updates, you might be
>> able to fix your situation by following some of the advice from the
>> "RECOVERING FROM UPSTREAM REBASE" section of the "git rebase" manual
>> (https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html). If that
>> doesn't make any sense to you or you encounter too much trouble with it then
>> you have a couple of options:
>>
>> A) Assuming you only use your cloned version of the repository to generate
>> small patch sets, you can always clone another copy of the repository and
>> move your patches over by hand.
>>
>> B) You may contact me with a clear explanation of your situation and I will
>> attempt to point you in the right direction and clear up any confusion about
>> the recent repository changes. I won't do any work for you, but I'm happy
>> to help with explanation in an
