git/git-p4.py, branch v2.37.0-rc2

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

Merge branch 'tk/p4-utf8-bom'

2022-05-20T22:26:54Z

"git p4" update. * tk/p4-utf8-bom: git-p4: preserve utf8 BOM when importing from p4 to git

git-p4: improve encoding handling to support inconsistent encodings

2022-05-04T17:30:01Z

git-p4 is designed to run correctly under python2.7 and python3, but its functional behavior wrt importing user-entered text differs across these environments: Under python2, git-p4 "naively" writes the Perforce bytestream into git metadata (and does not set an "encoding" header on the commits); this means that any non-utf-8 byte sequences end up creating invalidly-encoded commit metadata in git. Under python3, git-p4 attempts to decode the Perforce bytestream as utf-8 data, and fails badly (with an unhelpful error) when non-utf-8 data is encountered. Perforce clients (especially p4v) encourage user entry of changelist descriptions (and user full names) in OS-local encoding, and store the resulting bytestream to the server unmodified - such that different clients can end up creating mutually-unintelligible messages. The most common inconsistency, in many Perforce environments, is likely to be utf-8 (typical in linux) vs cp-1252 (typical in windows). Make the changelist-description- and user-fullname-handling code python-runtime-agnostic, introducing three "strategies" selectable via config: - 'passthrough', behaving as previously under python2, - 'strict', behaving as previously under python3, and - 'fallback', favoring utf-8 but supporting a secondary encoding when utf-8 decoding fails, and finally escaping high-range bytes if the decoding with the secondary encoding also fails. Keep the python2 default behavior as-is ('legacy' strategy), but switch the python3 default strategy to 'fallback' with default fallback encoding 'cp1252'. Also include tests exercising these encoding strategies, documentation for the new config, and improve the user-facing error messages when decoding does fail. Signed-off-by: Tao Klerks Signed-off-by: Junio C Hamano

git-p4: preserve utf8 BOM when importing from p4 to git

2022-04-06T19:59:58Z

Perforce has a file type "utf8" which represents a text file with explicit BOM. utf8-encoded files *without* BOM are stored as regular file type "text". The "utf8" file type behaves like text in all but one important way: it is stored, internally, without the leading 3 BOM bytes. git-p4 has historically imported utf8-with-BOM files (files stored, in Perforce, as type "utf8") the same way as regular text files - losing the BOM in the process. Under most circumstances this issue has little functional impact, as most systems consider the BOM to be optional and redundant, but this *is* a correctness failure, and can have lead to practical issues for example when BOMs are explicitly included in test files, for example in a file encoding test suite. Fix the handling of utf8-with-BOM files when importing changes from p4 to git, and introduce a test that checks it is working correctly. Signed-off-by: Tao Klerks Signed-off-by: Junio C Hamano

git-p4: support explicit sync of arbitrary existing git-p4 refs

2022-04-06T19:59:40Z

With the --branch argument of the "sync" subcommand, git-p4 enables you to import a perforce branch/path to an arbitrary git ref, using a full ref path, or to refs/remotes/p4/* or refs/heads/p4/*, depending on --import-local, using a short ref name. However, when you later want to explicitly sync such a given ref to pick up subsequent p4 changes, it only works if the ref was placed in the p4 path *and* has only one path component (no "/"). This limitation results from a bad assumption in the existing-branch sync logic, and also means you cannot individually sync branches detected by --detect-branches, as these also get a "/" in their names. Fix "git p4 sync --branch", when called with an existing ref, so that it works correctly regardless of whether the ref is in the p4 path or not, and (in the case of refs in the p4 path) regardless of whether it has a "/" in its short name or not. Also add tests to validate that these branch-specific syncs work as expected. Signed-off-by: Tao Klerks Signed-off-by: Junio C Hamano

git-p4: sort imports

2022-04-01T20:15:44Z

Signed-off-by: Joel Holdsworth Signed-off-by: Junio C Hamano

git-p4: seperate multiple statements onto seperate lines

2022-04-01T20:15:44Z

PEP8 discourages the use of compound statements where there are multiple statements on a single line in the "Other Recommendations" section: https://www.python.org/dev/peps/pep-0008/#other-recommendations Signed-off-by: Joel Holdsworth Signed-off-by: Junio C Hamano

git-p4: move inline comments to line above

2022-04-01T20:15:44Z

PEP8 recommends that all inline comments should be separated from code by two spaces, in the "Inline Comments" section: https://www.python.org/dev/peps/pep-0008/#inline-comments However, because all instances of these inline comments extended to an excessive line length, they have been moved onto a seprate line. Signed-off-by: Joel Holdsworth Signed-off-by: Junio C Hamano