On Tue, 19 Aug 2014 01:22:24 -0700 (PDT) Sverre Moe <sverre....@gmail.com> wrote:
> What is the preferred Git best practice when it comes to commit > refactoring? > > When I refactor some Java files in Eclipse, Git recognizes it has > been renamed and places the file under "Changes to be committed". > I addition because the Java class file has been renamed the Class and > all other classes that has references to it is listed under "Changes > not staged for commit". [...] > Should I first commit the rename, and then commit the changes? [...] > What is the preferred Git best practice when it comes to commit > refactoring changes? My advice is to record the rename of the file and classes in it in a single commit. The reasoning is: this is a single change from the logical standpoint. The fact you *observe* Eclipse splitting your changes in two steps is just an artifact of how this is implemented in Eclipse. On a bare command-line you'd see these changes "combined" as being not staged for commit *unless* you have used `git mv` to rename the file before modifying it. Eclipse is just trying to be helpful for some imaginary general case. Another perspective is that Git is said to track not files but rather project contents (with file renaming being irrelevant to the evolution of the project's code). So you're advised to rather concentrate on how the contents (code) is change and only consider renames as a byproduct of the fact the code is organized in files. You might find this  interesting to get the idea better. 1. http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217 -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.