Andy Parkins wrote:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html