TODO:
* Don't use the name "master" for the main branch
(https://www.bbc.com/news/technology-53050955).
* Delete closed and merged branches (https://github.com/frej/fast-
export/issues/84).
* Add documentation to fast-downward.org
* Set repository to public

I think the first two points are done. The main documentation is not on our wiki but in the README of the conversion repository. On our wiki, we have a link to that on http://www.fast-downward.org/Releases

We decided to write the announcement email as part of the release email, so I would say it is not part of this issue.

Thanks, everyone! This is now marked as resolved, but there are open TODOs. These TODOs should either not be part of this issue (i.e., we can remove them), or we should mark this as "in progress" again.

If it helps, I'm available for discussion after the PhD defense (which is currently in the discussion stage).

Maybe it's best to hold this discussion live when Malte is available so we can directly make a decision.

I'm not sure if I understand the situation where -d would produce an error. From the stackoverflow page Jendrik linked, it sounds like this happens if you are on a branch that has no path in the tree to some commit on the branch you want to delete. Does this mean this happens for us only if the branch we delete is closed and merged into a branch other than main that itself is open and unmerged?

From our discussions, I thought, we want to delete only the closed and merge 
branches. Those should be safe with '-d'.

Did it happen on your test repository that '-d' tried to delete something and 
failed or that after conversion there was a branch left which you wanted 
deleted (in the later case, I would be fine by telling the user, if you have 
this, you can delete it manually)?

I am a bit hesitant to switch to -D, because I am afraid that some users have 
unmerged closed branches that they do not want to loose without being asked.

I tested the scripts again and made several small changes. The most critical one is 

-            call(["git", "branch", "-d", branch])
+            # Use -D to avoid "branch not fully merged" warning, which
+            # occurs when trying to delete a branch that is closed and merged
+            # into a non-"default" branch, even if that branch will not be closed
+            # (https://stackoverflow.com/questions/7548926).
+            call(["git", "branch", "-D", branch])

I'm unsure whether -D is the correct solution. Using -d has the advantage that we abort with an error if we're potentially making commits unreachable. But -d doesn't allow us to remove all closed-and-merged branches. Does someone have a better solution for this?

You're right. I didn't think it through.

I agree with Florian. The .hgignore file doesn't really hurt.

I would not treat removing .hgignore as part of this issue. The problem with this is that if the script does a commit to remove the file, this could lead to inconsistent repositories (if the commit is not at the same place in the history, for example if an older repository is converted). If we create a normal issue and commit for it outside of the conversion script, then getting from a .hgignore to a .gitignore is just a matter of merging with the main branch.

If you thought about removing it during the rewrite-history step, that would be an option but I don't see it as necessary to erase the file from history. I think a normal commit on the main branch that removes .hgignore and adds .gitignore would be fine. If we want to avoid commits on main, we could also create an issue for this.

Add TODO: remove .hgignore file.

> I fiddled around with filtering empty commits and noticed that the repository
> sizes differ greatly depending on whether the repo is freshly cloned or not.
> Long story short: I think we can only compare repository sizes of freshly
> clones repos.

I think it would make sense to end the script with a cloning step then, so this doesn't trip other people up.

The conversion script now removes empty commits.

I fiddled around with filtering empty commits and noticed that the repository sizes differ greatly depending on whether the repo is freshly cloned or not. Long story short: I think we can only compare repository sizes of freshly clones repos.

> Question: does the migration script prepend [issueXYZ] to all commit messages?

Yes, it does.

> Do we get Malte's final approval?

We have to finalize issue652 first, or else we cannot really look at the resulting repository properly.

I'll try to review the issue652 result repository ASAP, and it would be great if others could, too.

> I'm appending the result. If nobody objects, I'll let the conversion script
> remove all empty commits.

They are all tags and branch status changes, which makes sense because Mercurial doesn't allow commits that do nothing; they have to change a file or some metadata like the branch info. (A commit might of course be empty because our conversion ignores all files that it changes, but it seems that such commits were already previously dropped by the conversion script.)

Question: does the migration script prepend [issueXYZ] to all commit messages? If not, after dropping these commits, we lose any trace of which branch/issue a commit belonged to. Now, we can use the "start branch XYZ/stop branch XYZ" commits for this.

(I can also check this myself, but I want to look at the hg cleanup issue first.)

I used the following command to obtain a list of empty commits:

for sha in $(git rev-list --min-parents=1 --max-parents=1 --all); do if [ $(git rev-parse ${sha}^{tree}) == $(git rev-parse ${sha}^1^{tree} ) ]; then git log --format="%B" -n 1 ${sha}; fi; done | sed '/^[[:space:]]*$/d'| tee empty-commits.txt

I'm appending the result. If nobody objects, I'll let the conversion script remove all empty commits.

Thank you Florian for the review. All comments have been incorporated. The 
current state can be seen at:
https://github.com/aibasel/convert-downward/pull/3

Do we get Malte's final approval?

I'm done with my review. There was nothing major, so Patrick, once you incorporated the changes, I'd say this is ready for Malte's final approval.

Copied over some notes from the task board:

We decided to keep the repo at aibasel/convert-downward instead of including it in the main repository

Yes, we renamed master to main and we delete those branches that are closed AND 
have been merged (without history loss)

The TODOs in the summary are done, right?

The migration script is ready for the next round of reviewing.
It seems not to be possible to make a code review for a whole repository, thus, 
I do not show you a nice PR. Here is the code
https://github.com/aibasel/convert-downward/

TODO:
* Don't use the name "master" for the main branch (https://www.bbc.com/news/technology-53050955).

After sprint summary:

We want a tool which automatically converts our Fast Downward repositories from
mercurial to git.

I am working on this. A first (slightly outdated) version exists and can be seen at
https://github.com/aibasel/convert-downward/pull/2

TODO:
- finish conversion for .hgignore to .gitignore (by simple rules and a user
given list of mappings, by user I mean me who creates a default list for our
rules which cannot be converted automatically)
- all branches are open again. Decide what we want to do about them. One suggestion:
#Archive (maybe our new close) branch
git tag archive/<branchname> <branchname>
git branch -d <branchname>
git checkout master

# Reopen branch
git checkout -b new_branch_name archive/<branchname>