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.
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:
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 any reasonable capacity.
If you aren't experiencing any problems right now, you might want to wait to address the rewound history until the second (and hopefully final) rewind occurs. I don't have an ETA on this, as Eugene at Mellanox is handling the actual import/update and I believe there are a number of Israeli holidays on the calendar this week.