2

First the question:

Is there any tool or patch to git that makes it specifically store metadata about file renames (much like git-svn does with "git-svn-id")? Failing this, is there another DVCS that gives me fast local branches (like git) and proper file rename tracking (like bazaar)?

Now some background as to why I need this:

I started using git for a few months and I really like it. Except for the fact that it doesn't track renames.

In my opinion, the decision not to track renames is based on the faulty assumption that it's the content that matters, not the name. I disagree. Let me give you a real-world example.

I had a class RefinementPresentation which was used as a model in the view template of a web page. I move the class to a separate package (model) and then, because the class was more than simply a model and contained heavy logic, I refactored it by moving the logic to another class. As you can imagine, now the class bears little resemblance to the original class. But conceptually, it's the same thing - it's still the model for the view. And that is my point. Whether the file is the same file (renamed/moved) or a different file is a concept in my head, and no tool can or should attempt to do it for me. Being so different, no amount of heuristics or guessing will make git recognize that this is actually a moved file. Which means git log will never show me the history past move. Of course, the history is still there - it's not lost - it's simply harder to get to. Thus my question: is there a way to not have this inconvenience?

EDIT: move and refactor in separate commits is a good workaround, see comments below (thanks Eevee!).

Cristian Vasile Mocanu
  • 493
  • 5
  • 13
  • 3
    move and refactor the file in separate commits. – Eevee Feb 12 '13 at 06:55
  • possible duplicate of [How to REALLY show logs of renamed files with git?](http://stackoverflow.com/questions/5743739/how-to-really-show-logs-of-renamed-files-with-git) – CharlesB Feb 12 '13 at 07:11
  • As explained in the question, the files are really different, so "git log --follow" or similar commands can never help. I need a different way to track renames that doesn't try to guess them based on file content similarity. – Cristian Vasile Mocanu Feb 12 '13 at 07:20
  • @Eevee: I think this might be my answer. I though it doesn't make any difference if I move and refactor in separate commits (even read people saying so), but thinking about it, it makes sense: (1) the first commit (the move) will be properly detected as a move since very little changed (only the package declaration - I'm using java); (2) the second commit will be detected as a proper file change (since the name of the file wasn't changed). I will try this and mark the question as answered if it works properly. – Cristian Vasile Mocanu Feb 12 '13 at 07:23
  • Move and refactor in separate commits will indeed make git properly recognize what happened: "git log --follow" now shows the whole history as expected. Thanks, Eevee. – Cristian Vasile Mocanu Feb 12 '13 at 07:38
  • @Eevee: please add an answer (as opposed to a comment) so I can accept it, since (even though it's a workaround), it solves my problem – Cristian Vasile Mocanu Feb 12 '13 at 07:40

1 Answers1

3

Least effort, greatest reward: move and refactor the file in separate commits.

For what it's worth, git isn't totally crazy here and has various sensible reasons for what it does—not that it's much consolation. :)

Eevee
  • 47,412
  • 11
  • 95
  • 127
  • 1
    I read that post before and re-read it now. But even if it sounds nice in theory, as I shown before, it fails to recognize the real-world fact that whether it's a rename or not is a concept in the developer's head and sometimes has nothing to do with the content of the file, but rather with what the file represents. No tool can guess that. I would argue that even if it attempts, it should still track renames and fall-back to the algorithm of guessing when the rename metadata is missing (or when the developer chooses to use it instead of the metadata). – Cristian Vasile Mocanu Feb 13 '13 at 06:33
  • it's a little more complicated than that: why should i have to use my source control tool to perform filesystem operations? what about the merging problem? what about copies? should there be special handling when part of a file is moved to another file? how do you indicate THAT to the vcs? git never claimed to store your thought process—that's what commit messages are for. hell, the first line of its manpage calls it what it is: a stupid content tracker. – Eevee Feb 13 '13 at 19:55