Hi. I’ve discovered to my surprise that the Java-...

# intellij

[natpryce]

Hi. I’ve discovered to my surprise that the Java-to-Kotlin converter adds spurious rename commits to the Git history. I consider the converter messing with Git history at all to be a bug. And these rename commits interfere with the rebasing features of IntelliJ (for example, if you change the Java code in a historical version & rebase, the rebasing tries to merge the Java code changes with changes to the Kotlin file that occurred after conversion to Kotlin). Is there any way to turn this behaviour off?

[Mike]

This must be a new feature. The alternative is to have it appear as a delete and an add of a new file, so you lose all history for the changes.

I don't know if it's an option that can be changed, but think about the alternative, and which you'd rather have.

Lost history, or what you have now.

[natpryce]

The current behaviour creates commit of a .kt file with Java code in it, which is not correct.

[natpryce]

Whether it does a git rename or not, it should not commit anything until the entire conversion is done, and then let the user enter a commit message. It shouldn’t commit incorrect code or create commits that may violate local standards for commit naming.

[Mike]

It's a choice they've (IJ) has made based on feedback. People complained that Git didn't correctly handle the rename when the file got converted, so this is/was their answer.

Unfortunately I don't see an option flag to turn it off, unless the 'use new Kotlin converter' one also turns off the commit action.

So some people want what you want, others want what it currently does. 🤷

[Mike]

I do seem to recall them mentioning the change in a release notes, though. Most likely in the Kotlin plugin notes.

[natpryce]

Whichever way is chosen, the current behaviour is incorrect. The rename of the file should be staged, not committed. It should not be committed as a separate commit of an invalid file of Java syntax in a Kotlin source file.

[Mike]

Do you understand the core reasoning here? The flaw is in Git, and its handling of renames. If Mercurial had 'won', we wouldn't even need this workaround.

JB made the decision to put a 'rename file' commit in to maintain history. If you're ok with losing that file history, then just amend that commit, and put your message in. Easily worked around.

And raise a ticket suggesting they make this an option that can be turned off.

Stating that "Whichever way is chosen, the current behaviour is incorrect" is a very one-sided statement. JB didn't just change it because they felt like it. They had a number of users complain about the loss of file history.

Bottom-line. Git's decision to do 'magic' rename, rather than an explicit rename operation like Mercurial and others is the fundamental issue here.

[natpryce]

My argument is not that it should/shouldn’t be a rename. It’s that whichever decision is made, it should only be staged in the index and not committed separately to the rest of the translation.

[Mike]

I don't think you are getting it. If I have 'SomeBigClass.java' and do the conversion, and don't commit until I'm done making it 'SomeBigClass.kt', when I look at the history of 'SomeBigClass.kt', it will show as 'added' today.

If we do what IJ now does (commit right after rename, and then commit for conversion work), when I look at the history for SomeBigClass.kt, I will see the history of SomeBigClass.java as part of the history list.

If you don't care about that, then your approach is 'correct'.

If you DO care about that history, then IJ's approach is 'correct'.

Many users felt the latter was 'better'. You (and others will, too) disagree.

IMO, IJ should make it a flag, or prompt on conversion or somehow make it optional/visible to users. But neither approach is correct, and neither is wrong. Fundamentally all of this is working around an issue in Git's rename detection strategy.

[natpryce]

👍

[natpryce]

Or rather, this is a transformation that is neither a rename, nor a delete and add of unrelated files, and therefore is not representable in Git (or any other version control system I know of)

[Mike]

I see it as more of a rename than it not being one. It's a translation, but the functionality is the same. So it's a refactor that falls through the cracks because of the necessity to rename the file. I like to see the history before, because it can help explain why the code is the way it is now, regardless of language.

Really, if our file systems used type information about files, it could just be called SomeBigClass with a type of Java, and it switches to Kotlin. Then Git could say 'it is the same' but let you know about the type change.

But that won't happen anytime soon.

[Alexey Belkov [JB]]

To disable this, please turn off the option "Extra commit for .java > .kt renames" in the commit dialog (it's only visible if there has been a J2K conversion to be commited).

If you feel that this feature is problematic can you please create an issue at http://kotl.in/issue and describe your use case? Thanks!