That's because git doesn't store that it was a rename. It just stores the files as they are, and only works out that it was a rename when you do a git log, etc.
Sometimes you'll see evidence of that, if you rename and modify a file you may see 99% in the git status, as it's not entirely confident that there was a rename. This approach initially sounds more primitive than svn's, but it means that if there are advances in rename detection all your old commits suddenly benefit; you don't need to reprocess them in some way. On Wed, Feb 9, 2011 at 11:01 PM, Josh Berry <[email protected]> wrote: > On Wed, Feb 9, 2011 at 5:57 PM, Ricky Clarkson <[email protected]> > wrote: >> If you rename a file, for example, when using git, git isn't going to >> realise unless you explicitly git add the new file (or your IDE does >> so), unless I've missed something. (or you use git mv to rename it). >> So I don't know what you mean about it analysing the filesystem and >> figuring everything out. > > It is nice that you simply have to add the file to the commit. You > don't have to specifically point out that it was a rename/copy. I > understand this isn't always perfect, but I don't recall any times it > has been wrong where I would have cared. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
