search

eclipse-egit / egit

EGit, the git integration of Eclipse IDE
https://www.eclipse.org/egit/
Eclipse Public License 2.0
13 stars 6 forks source link

Renaming/moving files around are not usually captured as git changes #29

Closed CarlosMOGoncalves closed 3 months ago

CarlosMOGoncalves commented 3 months ago

Version

6.5

Operating System

Windows

Eclipse version

2023-03

Bug description

  1. Rename a class into something else.
  2. Perform any other change, i.e. add a new fields or annotations
  3. Stage the changes and commit them
  4. History is gone

Actual behavior

This happens as well when moving a class somewhere else. It has been happening at least since 6.5, but it is likely been like this for a long time. I just started noticing it in the past year.

I can't quite figure the pattern for when it decides to keep the history and when it makes it gone.

It appears that if you just rename a class and make no other changes, it will keep its history, effectively capturing the rename as if was the subject to a git mv. Similarly, If you just move a class and commit, it will also behave correctly as if the file was just git mved.

As you can see below, I have taken a file and moved it from one package to another without making any change (besides the package header, naturally): image

If you perform some changes to the contents of the file, it will definitely consider it as if it was a new file, erasing all history, greatly damaging the project history.

Below you can see that I have moved this class from one package to another and also played around with its internal structure. Now it considers it a completely new file, written from the ground up and all its past history is gone! image

However, I do have a case where I performed another minor change to the class contents and it still kept history, as can be seen below: image

Expected behavior

Whenever one moves files between packages and makes some changes it should keep all its history, on commit, as if the file was manually subject to a git mv, then changed at will and finally commited.

Relevant log output

No response

Other information

Well, I have installed on my machine the git for Windows, version 2.44.0, but I assume that is irrelevant because you likely use an embedded git in eclipse.

tomaswolf commented 3 months ago

git does not record information about moves, i.e., renamed files. "renamings" are detected by content similarity. The corresponding code in C git has seen a few improvements in recent years (IIRC also considering file names and directory names and having a notion of a "directory rename"); it's possible that the JGit implementation does not have all these improvements.

CarlosMOGoncalves commented 3 months ago

Well, that does explain what the history tool display stating "similarity" (i.e. it states that the renamed file is xx% similar to its original).

I have just tried a similar refactoring resorting directly to git commands and indeed, if I rename a file and perform several changes to it, it will be understood as a new file and so, it will have no history.

In short, we can conclude that rather than a bug this is instead the way git works and refactors should be conducted with caution, probably renaming or moving in one commit and only then undertaking code refactoring on the file itself so that git catches the changes into history, right?

tomaswolf commented 3 months ago

Yes, that summary is correct.

CarlosMOGoncalves commented 3 months ago

That's nice. That was enlightening. Thank you for your time. I will close this.