Philip Oakley <philipoakley@iee.email> writes:
Hi Philip,
>> I wish there was some to tell Git a file was renamed (not one deleted
>> and another one added) after the fact (i.e. the refactoring
>> operation). Maybe something like "git add --rename OLD NEW" where
>> the following "git commit" would actually create two commits, one
>> artificial one to track the renames and nothing else (with a clearly
>> distinguishable message), and one with my own commit message for the
>> remainder (the changed contents).
>>
> I guess that one thing to look at would be how the --follow options
> work, and see if there is a mechanism, via the .gitattributes that
> allows files ("*.java" etc) to be designated as having a particular
> follow type where some assistance is given by some regex as to how to
> spot the relevant parts of one source file that could have changed to
> match a filename change elsewhere.
Sorry, I can't quite follow (pun intended) as my gitattributes foo is
rather weak. What I see from "git log --help" is that maybe I could
adjust the values of --find-renames and --find-copies (is that the same
as the diff.renames config option?).
> I'm thinking here about a comparison with the diff regexes used for
> defining the function context of a change. There are a wide range of
> default patterns used for that purpose for the different languages
> when applied to diffs. Maybe one could be generated for the --follow
> issue?
Do you have an example at hand which illustrates what you're thinking
about?
And for illustration purposes, that would be a typical Java file
Foo.java:
--8<---------------cut here---------------start------------->8---
package some.package.foo;
public class Foo implements Comparable<Foo> {
public Foo() {
...
}
public Foo(int x) {
...
}
public int compare(Foo other) {
...
}
public boolean equals(Object other) {
if (other instanceof Foo) {
Foo other = (Foo) other;
...
}
return false;
}
public doStuff() {
...
}
}
--8<---------------cut here---------------end--------------->8---
When renaming the class to Bar (which would inevitable change at least 6
lines in this contrieved example) the file also needs to be renamed to
Bar.java.
That said, the problem isn't so bad in most practical scenarios.
Usually, Git recognizes the renames pretty well because there's enough
contents which don't change. It just happens when files are rather
small, self-referential or get refactored too much, and in these cases,
one might argue that revision N and N+1 really don't have much in
common.
Bye,
Tassilo
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/87a77tq5zq.fsf%40gnu.org.
