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 ,
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
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. ;-)
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
For more options, visit https://groups.google.com/d/optout.