Hi Tassilo,
On 13/12/2019 08:57, Tassilo Horn wrote:
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.
I'm not a user of such languages (I'm a bit old school...) that mix
filenames into code, so a bit of ignorance here on that.
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).
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.
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?
Philip
--
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/90f60d39-ab8d-4c83-8873-4342a8b1b23c%40iee.email.
