git/git-p4.py, branch v2.41.2

Merge branch 'kk/p4-client-name-encoding-fix'

2022-08-01T16:58:37Z

"git p4" did not handle non-ASCII client name well, which has been corrected. source: * kk/p4-client-name-encoding-fix: git-p4: refactoring of p4CmdList() git-p4: fix bug with encoding of p4 client name

Merge branch 'mb/p4-utf16-crlf'

2022-07-27T16:16:55Z

"git p4" working on UTF-16 files on Windows did not implement CRLF-to-LF conversion correctly, which has been corrected. * mb/p4-utf16-crlf: git-p4: fix CR LF handling for utf16 files

git-p4: refactoring of p4CmdList()

2022-07-21T16:47:06Z

The function p4CmdList executes a Perforce command and decodes the marshalled python dictionary. Special care has to be taken for certain dictionary values which contain non-unicode characters. The old handling contained separate hacks for each of the corresponding dictionary keys. This commit tries to refactor the coding to handle the special cases uniformely. Signed-off-by: Kilian Kilger Signed-off-by: Junio C Hamano

git-p4: fix error handling in P4Unshelve.renameBranch()

2022-07-20T20:53:54Z

The error handling code path is meant to be triggered when the loop does not exit early via "break". This fails, as the boolean variable "found", which is used to track whether the loop was exited early, is initialized incorrectly. It would be possible to fix this issue by correcting the initialization, but Python supports a for:-else: control flow construct for this exact use case (executing code if a loop does not exit early), so it is more idiomatic to remove the tracking variable entirely. In addition, the error message no longer refers to a variable that does not exist. Signed-off-by: Moritz Baumann Signed-off-by: Junio C Hamano

git-p4: fix typo in P4Submit.applyCommit()

2022-07-20T20:53:52Z

Signed-off-by: Moritz Baumann Signed-off-by: Junio C Hamano

git-p4: fix CR LF handling for utf16 files

2022-07-20T18:38:06Z

Perforce silently replaces LF with CR LF for "utf16" files if the client is a native Windows client. Since git's autocrlf logic does not undo this transformation for UTF-16 encoded files, git-p4 replaces CR LF with LF during the sync if the file type "utf16" is detected and the Perforce client platform indicates that this conversion is performed. Windows only runs on little-endian architectures, therefore the encoding of the byte stream received from the Perforce client is UTF-16-LE and the relevant byte sequence is 0D 00 0A 00. Signed-off-by: Moritz Baumann Signed-off-by: Junio C Hamano

git-p4: fix bug with encoding of p4 client name

2022-07-08T14:59:12Z

The Perforce client name can contain arbitrary characters which do not decode to UTF-8. Use the fallback strategy implemented in metadata_stream_to_writable_bytes() also for the client name. Signed-off-by: Kilian Kilger Reviewed-by: Tao Klerks Signed-off-by: Junio C Hamano

Merge branch 'tk/p4-metadata-coding-strategies'

2022-05-20T22:27:00Z

"git p4" updates. * tk/p4-metadata-coding-strategies: git-p4: improve encoding handling to support inconsistent encodings

Merge branch 'kf/p4-multiple-remotes'

2022-05-20T22:26:55Z

"git p4" update. * kf/p4-multiple-remotes: git-p4: fix issue with multiple perforce remotes

Merge branch 'tk/p4-with-explicity-sync'

2022-05-20T22:26:55Z

"git p4" update. * tk/p4-with-explicity-sync: git-p4: support explicit sync of arbitrary existing git-p4 refs