Fix order of commits

[PatrickFerber]

For the users cleaned up and converted repository to be compatible with our primary git repository, the users repository need to have the commits in the right order. This has to be ensured!

1. clone the Mercurial master repository anew (do not allow the user to use a local version, because until recently the clone from hg.fast-downward.org was also in a wrong order)
2. strip away new commits from master repository
3. pull the user repository in the stripped master repository
   -> your changes are in the repository and the old commits have the right order!

[maltehelmert]

I don't understand who this comment is directed to. Who is the "you" we're talking to here? The user of the script? Which commits are meant by "new commits" in point 2, and why do they need to be stripped? No commits need to be stripped from the master repository, and clearly if the user's commits are stripped, they won't be converted. Under point 1, I don't understand what the part in parentheses wants to stay. Is "do now" a typo?

[PatrickFerber]

update initial post (you -> user, fix typo, rephrasing)

In the case the user did his developments on the 'default' branch, we need to strip the commits on the default branch.
Furthermore, if I convert an X year old Fast Downward repository, I would not expect that the new developments of Fast Downward will be pulled into my repository.

[PatrickFerber]

Here is the PR: #6

[maltehelmert]

I see. (Florian explained the rationale to me.) I wouldn't have offered support for conversion for people that are not ready to pull from the final hg version. I think the use case for a git conversion compatible with our repository is weak for people who are not willing to get at least that up to date. But if that's what you prefer, I won't object.

[silvansievers]

I also previously advocated against providing support for people who don't want to update their branches to the latest default.