Philip Oakley writes:
> The best way at the moment is NOT to both change the filename, and
> some content, in the same step. Rather, change the filename in commit
> 1, and then change content in commit 2.
I can second that but it is a quite a pain at least for programming
languages where file contents and filename are intertwined, e.g., Java.
Usually, you'd just use your IDE's rename refactoring function which
changes both (and all usages) but sometimes that's already too much
change of contents so that Git considers that renamed file to be
completely new.
So in such scenarios, you have to choose between
(a) keeping the history intact for the price of more manual work and
at least one commit which won't even compile,
(b) less work and all versions compile but a cut in the history.
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).
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/git-users/913d882a-f623-4dfe-baba-e814e06704ad%40googlegroups.com.
