Moving files in Git

[FluffyFreak]

Recently a lot of files have been, and are being, moved around into subfolders etc.

This is making it really difficult to backtrack and follow the history of files which on a project this long lived is really important for tracking bugs and functionality.

There's an easy way to avoid this being a problem though, because Git can handle files being moved, it can detect them if they're identical before and after the move so long as they're committed immediately.

So I'm asking if we can follow this process for moving files around:
1. Do NOT change the files in any way
2. Move the unchanged file to the new location
3. Commit the moved files immediately
4. Then fixup the files for their new location or make any other changes!

If we do this, and if it works, then following changes back through the history of the files should be much easier.

What do people think?

[impaktor]

Well, "git status" before commit should show if git correctly understood that the files have just been "renamed" which is what git calls a moved file, I think.

Code: Select all

git mv <from> <to>

[GunChleoc]

Yes, definitely use the git mv command.

[FluffyFreak]

Is there a way to reassociate files that have already been moved?

[FluffyFreak]

There are pending PR's where files have been moved by just moving them, but with edits, so Git doesn't automatically track them. Even git mv just moves them with a commit, there's no other magic "move" command it just does what I've suggested above as far as I can tell.

[impaktor]

Even git mv just moves them with a commit

Well, yes, just doing a chmod on a file will create a commit, but as long as it's not removing all old code, and creating all code anew, then it's fine, and git mv should behave sanely.

Any example of such a PR?

[FluffyFreak]

Every commit that has moved something into the `\src\ship` folder