I've learned this the hard way, and I've had to learn it several times because I am a slow learner. I've posted this before, and repeat it because bears repeating.

The procedure is:

1. pass the test suite
2. prep the file for conversion, i.e. try to minimize the use of idioms that won't easily translate
3. pass the test suite
4. translate the code with as few edits as practical. Do not reformat the code. Do not refactor it. Do not fix anything, no matter how tempting. Reproduce the behavior of the original as much as possible.
5. pass the test suite
6. now reformat, refactor, fix (as separate PRs, of course, and passing the test suite in between each).
7. pass the test suite

Note that without a test suite, you're doomed :-)

On Friday, 21 September 2018 at 06:00:33 UTC, Walter Bright wrote:
> I've learned this the hard way, and I've had to learn it several times because I am a slow learner. I've posted this before, and repeat it because bears repeating.

I find this is a great procedure for any sort of large refactoring -- minimal changes at each step and ensure tests are passing after every change.

Thanks for sharing!

On Thu, 20 Sep 2018 23:00:33 -0700, Walter Bright wrote:

> The procedure is:
> ...
> 4. translate the code with as few edits as practical. Do not
> reformat the code. Do not refactor it. Do not fix anything, no matter
> how tempting. Reproduce the behavior of the original as much as
> possible.

I'd add 4b: file an issue for anything that needs to be fixed; otherwise it's quickly forgotten.

On Friday, 21 September 2018 at 06:24:14 UTC, Peter Alexander wrote:
> On Friday, 21 September 2018 at 06:00:33 UTC, Walter Bright wrote:
>> I've learned this the hard way, and I've had to learn it several times because I am a slow learner. I've posted this before, and repeat it because bears repeating.
>
> I find this is a great procedure for any sort of large refactoring -- minimal changes at each step and ensure tests are passing after every change.
>

Also, use a git commit for each logical change. If you discover a change that should have been put in a previous commit, use rebase --interactive to put it in right commit (of course that branch you're working on is purely local). Only when all the changes have been made can you decide to squash or not, or reorder them, or push them partially.

TL;DR

git can help to organize the refactoring, not be solely a recording device.