On Wed, 1 Jul 2015 07:49:45 -0700 (PDT) Oliver Schrenk <oliver.schr...@gmail.com> wrote:
> I want to migrate some legacy java code to scala whilst keeping git > history intact for each file. The idea was to do a very basic > conversion first, just doing ssyntactical changes first and have git > mark it only as a rename and go from there. Do I understand correctly that conversion also implies explicit renaming of files (like changing their extension from ".java" to ".scala" or something like this)? > But already the basic syntax changes push git over the similarity > edge, so now II have a deleted file, and a new file. My understanding > is then that I basically loose history as I don't see the full > history of the "new" file. `git log --follow <file>` doesn't work. Does `git log --follow -M5% path/to/that/file/name` help? By default, Git uses the similarity threshold of 50% when it tries to detect file rename, so by tweaking this parameter you could make it more happy with your changes. > Can I mark file changes manually as a rename? No, you can't. What `git commit` shows you as a rename is just a heuristic intended to aesthetically please the user -- it's not recorded in the repository as such in any way. Each commit in a Git repository references a single tree object, which references blob objects representing its files and other tree objects representing its subdirectories, and so on. Tree objects contain short (relative) names for their entries and have no idea about tree objects representing the same directory in past commits. > Are there different approaches? Well, one working different approach is to adopt the Git's approach to your changes rather than trying to go against the grain. In [1], the creator of Git explains in detail why Git implements the model which does not explicitly track files but rather considers them as mere blobs forming the project as a whole (which is a tracking unit in Git). (The bottom line of that explanation is that "the reference project for Git" -- which is Linux -- could not live with rename tracking, and so it's absent.) You will certainly not lose history as it will be available via the regular parent/child relations of the commits in your repository. Now you're maintaining the "file-based" mental model and hence obviously what you're facing now is a problem. If you will change your mental model to consider your whole project as a tracking unit, your history is all there again. Please understand that I'm not here to claim that being able to do `git log -- path/to/file` is worthless but from personal experience I know that indeed obviously it works only for "stabilized" files, which receive only small amounts of changes per commit. On the other hand, the "-S" and "-R" options to `git log` provide you with a powerful tool for a larger scale. And so does `git grep` with its ability to search through a given commit. May be those will be enough to make you cope with the situation without trying to fight Git. ;-) 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.
