> git-p4 can map a "git move" operation to a Perforce "move" operation.
> But by default this is disabled. You then end up with a P4 commit
> where the file is deleted, and a fresh file is created with the same
> contents at the new location at revision #1.
>
> Rename detection gets enabled either with the "-M" option, or with
> some config variables, git-p4.detectCopies and git-p4.detectRenames.
>
> I've been tripped up by this, and I actually know about it, and I know
> other people have been as well.
>
> Should we switch the default over so that it's enabled by default? I
> can't think of any reason why you wouldn't want it enabled.
I have it enabled in my ~/.gitconfig,
so enabling it by default makes total sense to me.
Regarding potential problems,
I occasionally get a wrong "source" file detection.
(e.g. there was `cp a b ; git add b`, but some other file "c" is selected as
the source instead)
Or there is a "copy/move" detected, when there was actually none.
But I've only seen this with quite small files (like a trivial one line shell
script) or binaries,
and mostly because I have git-p4.detectCopiesHarder set as well as a pretty
aggressive git-p4.detectCopies threshold.
(normally 30%, but down to 10% at times to make sure a copy/move is really
detected)
But anyway, enabling both git-p4.detect{Copies,Renames}
with default 50% similarity index makes sense to me.
It's probably worth adding command-line options to override the new to-be
defaults though.
A more conservative approach like only enabling git-p4.detectRenames = 70% is
an option too.
>
> I think the rename code was first introduced around 2011 by Vitor.
>
> Another option is to add a warning, but people just ignore warnings!
When such a warning would be shown?
Just before `p4 submit`?
I think, It might be hard to notice for large changesets.
Thank you,
Andrey
