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

Merge branch 'jt/p4-spell-re-with-raw-string'

2024-02-06T22:31:20Z

"git p4" update to squelch warnings from Python. * jt/p4-spell-re-with-raw-string: git-p4: use raw string literals for regular expressions

git-p4: use raw string literals for regular expressions

2024-01-29T17:25:16Z

Fixes several Python diagnostics about invalid escape sequences. The diagnostics appear for me in Python 3.12, and may appear in earlier versions. The fix is to use raw string literals so that backslashes are not interpreted as introducing escape sequences. Raw string literals are already in use in this file, so adding more does not impact toolchain compatibility. Signed-off-by: James Touton Signed-off-by: Junio C Hamano

git-p4: stop reaching into the refdb

2024-01-11T21:10:41Z

The git-p4 tool creates a bunch of temporary branches that share a common prefix "refs/git-p4-tmp/". These branches get cleaned up via git-update-ref(1) after the import has finished. Once done, we try to manually remove the now supposedly-empty ".git/refs/git-p4-tmp/" directory. This last step can fail in case there still are any temporary branches around that we failed to delete because `os.rmdir()` refuses to delete a non-empty directory. It can thus be seen as kind of a sanity check to verify that we really did delete all temporary branches. Another failure mode though is when the directory didn't exist in the first place, which can be the case when using an alternate ref backend like the upcoming "reftable" backend. Convert the code to instead use git-for-each-ref(1) to verify that there are no more temporary branches around. This works alright with alternate ref backends while retaining the sanity check that we really did prune all temporary branches. This is a modification in behaviour for the "files" backend because the empty directory does not get deleted anymore. But arguably we should not care about such implementation details of the ref backend anyway, and this should not cause any user-visible change in behaviour. Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

git-p4 shouldn't attempt to store symlinks in LFS

2023-10-19T17:57:44Z

git-p4.py would attempt to put a symlink in LFS if its file extension matched git-p4.largeFileExtensions. Git LFS doesn't store symlinks because smudge/clean filters don't handle symlinks. They never get passed to the filter process nor the smudge/clean filters, nor could that occur without a change to the protocol or command-line interface. Unless Git learned how to send them to the filters, Git LFS would have a hard time using them in any useful way. Git LFS's goal is to move large files out of the repository history, and symlinks are functionally limited to 4 KiB or a similar size on most systems. Signed-off-by: Matthew McClain Signed-off-by: Junio C Hamano

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