Andy Parkins wrote: > On Tuesday 2006, November 28 19:11, Nicholas Allen wrote: > >> This can't be fail safe though. I would prefer to also have the option >> to be able to *explicitly* tell the RCS that a file was renamed and not >> have it try to detect from the content which is bound to have corner >> cases that fail. When I know I renamed a file why can't I explicitly > > You want to tell git about a rename that will never fail to be detected? No > problem. > > $ git mv oldname newname > $ git commit > > The corner cases you speak about are when you rename and edit. > > For me, I prefer that to be detected as at least the detection algorithm can > be tuned - there is no fixing it if the VCS was forced to consider it a > rename. > > When I started using git I was worried about the lack of a rename, but now I > realise that it's not needed - it's pointless. The VCS is snapshotting > moments in time, that's it. Then by making cleverer and cleverer > interpreters of those snapshots you have the potential to do stuff that is > far more useful than "just" rename recording. Well, there are two cases where this might be not enough. On is following file renames for history tracking. git-blame does that, but git-log and friends does not; the <path> is just revision limiter. There is an idea of --follow option to git-log (and friends), to be implemented. Second is rename detection for 3way merges: only ancestor and final states are considered, so the above would not help. And rename detection might fail if ancestor is not similar enough to end states; well, the merge has low chance of being without conflict then. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html