Re: [PATCH 4/4] git-p4: resolve RCS keywords in binary

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 13, 2021, 23:34 UTC
Message-ID: <xmqqzgp484f3.fsf@gitster.g>
In-Reply-To: <20211213225441.1865782-5-jholdsworth@nvidia.com>

Joel Holdsworth <jholdsworth@nvidia.com> writes:

Show 20 quoted lines

> RCS keywords are strings that will are replaced with information from
> Perforce. Examples include $Date$, $Author$, $File$, $Change$ etc.
>
> Perforce resolves these by expanding them with their expanded values
> when files are synced, but Git's data model requires these expanded
> values to be converted back into their unexpanded form.
>
> Previously, git-p4.py would implement this behaviour through the use of
> regular expressions. However, the regular expression substitution was
> applied using decoded strings i.e. the content of incoming commit diffs
> was first decoded from bytes into UTF-8, processed with regular
> expressions, then converted back to bytes.
>
> Not only is this behaviour inefficient, but it is also a cause of a
> common issue caused by text files containing invalid UTF-8 data. For
> files created in Windows, CP1252 Smart Quote Characters (0x93 and 0x94)
> are seen fairly frequently. These codes are invalid in UTF-8, so if the
> script encountered any file containing them, on Python 2 the symbols
> will be corrupted, and on Python 3 the script will fail with an
> exception.

Makes sense, and I am with others who commented on the previous discussion thread that the right approach to take is to take the stuff coming from Perforce as byte strings, process them as such and write them out as byte strings, UNLESS we positively know what the source and destination encodings are.

And this change we see here, matching with patterns, is perfectly in line with that direction. Very nice.

>          try:
> -            with os.fdopen(handle, "w+") as outFile, open(file, "r") as inFile:
> +            with os.fdopen(handle, "wb") as outFile, open(file, "rb") as inFile:

We seem to have lost "w+" and now it is "wb". I do not see a reason to make outFile anything but write-only, so the end result looks good to me, but is it an unrelated "bug"fix that should be explained as such (e.g. "there is no reason to make outFile read-write, so instead of using 'w+' just use 'wb' while we make it unencoded output by adding 'b' to it")?