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 [1]
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.

Reply via email to