Re: [PATCH v3] git-p4: recover from inconsistent perforce history

Luke Diamand [off-list ref] writes:

On Sun, 10 May 2020 at 11:17, Andrew Oakley [off-list ref] wrote:

quoted

Perforce allows you commit files and directories with the same name, so
you could have files //depot/foo and //depot/foo/bar both checked in.  A
p4 sync of a repository in this state fails.  Deleting one of the files
recovers the repository.

When this happens we want git-p4 to recover in the same way as perforce.

Looks good to me.

Perforce changed their server to reject this kind of thing in the
2017.1 version:

    Bugs fixed in 2017.1
    #1489051 (Job #2170) **
       Submitting a file with the same name as an existing depot
       directory path (or vice versa) will now be rejected.

(Of course people will still have damaged repos even today).

Perhaps it is worth describing the above in the log message?  E.g.

    Perforce allows you commit files and directories with the same name,
    so you could have files //depot/foo and //depot/foo/bar both checked
    in.  A p4 sync of a repository in this state fails.  Deleting one of
    the files recovers the repository.

    When this happens we want git-p4 to recover in the same way as
    perforce.

    Note that Perforce has this change in their 2017.1 version:

         Bugs fixed in 2017.1
         #1489051 (Job #2170) **
            Submitting a file with the same name as an existing depot
            directory path (or vice versa) will now be rejected.

    so people hopefully will not creating damaged Perforce repos
    anymore, but "git p4" needs to be able to interact with already
    corrupt ones.

    Signed-off-by: Andrew Oakley [off-list ref]
    Reviewed-by: Luke Diamand [off-list ref]
    Signed-off-by: Junio C Hamano [off-list ref]

Thanks.