Python 3 support for git_remote_helpers

Change inline Python to call "print" as a function not a statement.

This is harmless because Python 2 will see the parentheses as redundant grouping but they are necessary to run this code with Python 3.

Signed-off-by John Keeping <[email protected]>

Although 2to3 will fix most issues in Python 2 code to make it run under Python 3, it does not handle the new strict separation between byte strings and unicode strings. There is one instance in git_remote_helpers where we are caught by this, which is when reading refs from "git for-each-ref".

Fix this by operating on the returned string as a byte string rather than a unicode string. As this method is currently only used internally by the class this does not affect code anywhere else.

Note that we cannot use byte strings in the source as the 'b' prefix is not supported before Python 2.7 so in order to maintain compatibility with the maximum range of Python versions we use an explicit call to encode().

Quoted 6 lines · John Keeping

Although 2to3 will fix most issues in Python 2 code to make it run under Python 3, it does not handle the new strict separation between byte strings and unicode strings. There is one instance in git_remote_helpers where we are caught by this, which is when reading refs from "git for-each-ref".

Quoted 8 lines

Fix this by operating on the returned string as a byte string rather than a unicode string. As this method is currently only used internally by the class this does not affect code anywhere else.

Note that we cannot use byte strings in the source as the 'b' prefix is not supported before Python 2.7 so in order to maintain compatibility with the maximum range of Python versions we use an explicit call to encode().

The three patches that deal with .encode() stuff (2, 7, 8) make me a bit uncomfortable, as they add some significant complexity to our python code. Is this the recommended way to deal with this (similar to the other patch where you linked to the python wiki explaining)?

As one datapoint, it seems that it's actually Python 2.6 that introduces the b prefix.

http://www.python.org/dev/peps/pep-3112/

When did we last revisit what minimal python version we are ok with requiring?

Quoted 1 line

When did we last revisit what minimal python version we are ok with requiring?

I was wondering if people would weigh in discussing that in response to
[1] but no one has commented on that part of it. As another datapoint, Brandon Casey was suggesting patching git-p4.py to support Python 2.4 [2].

[1] http://article.gmane.org/gmane.comp.version-control.git/213920
[2] http://article.gmane.org/gmane.comp.version-control.git/214048

Quoted 7 lines · John Keeping

Quoted 1 line

When did we last revisit what minimal python version we are ok with requiring?

I was wondering if people would weigh in discussing that in response to
[1] but no one has commented on that part of it. As another datapoint, Brandon Casey was suggesting patching git-p4.py to support Python 2.4 [2].

Quoted 2 lines

[1] http://article.gmane.org/gmane.comp.version-control.git/213920
[2] http://article.gmane.org/gmane.comp.version-control.git/214048

I for one would be happy to kill off support for anything older than 2.6 (which had it's latest release on October 1st, 2008).

Junio, how have we decided in the past which version of x to support?

Quoted 8 lines · Sverre Rabbelier

Quoted 7 lines · John Keeping

Quoted 1 line

When did we last revisit what minimal python version we are ok with requiring?

I was wondering if people would weigh in discussing that in response to
[1] but no one has commented on that part of it. As another datapoint, Brandon Casey was suggesting patching git-p4.py to support Python 2.4 [2].

Quoted 7 lines

Quoted 2 lines

[1] http://article.gmane.org/gmane.comp.version-control.git/213920
[2] http://article.gmane.org/gmane.comp.version-control.git/214048

I for one would be happy to kill off support for anything older than 2.6 (which had it's latest release on October 1st, 2008).

Junio, how have we decided in the past which version of x to support?

I do not think there was any conclusion. $gmane/212215 claiming 2.4 support matters for RHEL 5.x users was the last on the topic as far as I can tell, so it boils down to another question: do users on RHEL 5.x matter?

I can read from $gmane/212215 that users of the said platform can safely keep using Python 2.4 under their vendor support contract until 2017. But let's focus on what do these users expect of their system and software they run on it a bit.

When they want to run a piece software that is not shipped with RHEL, either by writing their own or by importing from elsewhere, that needs 2.6 features, what are their options?

(a) The platform vendor optionally supplies 2.6 with or without

     support;

(b) The users can and do install 2.6 as /usr/local/bin/python2.6, which may even be community-supported, but the vendor does not support it; or

(c) The vendor terminates the support contract for users who choose

     to go (b).

I think we can safely discard (c); if that is the case, the users on the said platform will not choose to update Git either, so it does not matter where the future versions of Git sets the lower bound of Python version at.

If we are not talking about the situation (c), then the users can choose to use 2.6, and more importantly, Python being a popular software, I would imagine that there are reputable sources of prepackaged RPMs for them to do so without going too much hassle of configuring, compiling and installing.

Now how does the decision we make today for releases of Git that haven't yet happened will affect these users? As these versions of newer Git were not shipped with RHEL 5.x, and also I am assuming that Git is a more niche product than Python is, I would imagine that it is very unlikely that the vendor gives it the users as an optional package. The users will have to do the same thing to be able to use such versions of Git as whatever they do in order to use Python 2.6.

Given that, what the vendor originally shipped and officially supports does not affect the choices we would make today for newer versions of Git. The users in a shop where additional third-party software in /usr/local/bin is strictly forbidden, they are stuck with the version of Git that the vendor shipped anyway, because they won't be able to install an updated Git in /usr/local/bin, either.

That is, unless installing 2.6 as /usr/local/bin/python2.6 (or if you are really paranoid, /usr/local/only-for-git/bin/python2.6 where nobody's $PATH points at) is impossible.

So personally I do not think dropping 2.4 is a huge problem for future versions of Git, but I'd like to hear from those working in IT support for large and slow-moving organizations (aka RHEL 5 customers).

Quoted 69 lines · Junio C Hamano

Quoted 8 lines · Sverre Rabbelier

Quoted 7 lines · John Keeping

Quoted 1 line

When did we last revisit what minimal python version we are ok with requiring?

I was wondering if people would weigh in discussing that in response to
[1] but no one has commented on that part of it. As another datapoint, Brandon Casey was suggesting patching git-p4.py to support Python 2.4 [2].

Quoted 7 lines

Quoted 2 lines

[1] http://article.gmane.org/gmane.comp.version-control.git/213920
[2] http://article.gmane.org/gmane.comp.version-control.git/214048

I for one would be happy to kill off support for anything older than 2.6 (which had it's latest release on October 1st, 2008).

Junio, how have we decided in the past which version of x to support?

I do not think there was any conclusion. $gmane/212215 claiming 2.4 support matters for RHEL 5.x users was the last on the topic as far as I can tell, so it boils down to another question: do users on RHEL 5.x matter?

I can read from $gmane/212215 that users of the said platform can safely keep using Python 2.4 under their vendor support contract until 2017. But let's focus on what do these users expect of their system and software they run on it a bit.

When they want to run a piece software that is not shipped with RHEL, either by writing their own or by importing from elsewhere, that needs 2.6 features, what are their options?

(a) The platform vendor optionally supplies 2.6 with or without

     support;

(b) The users can and do install 2.6 as /usr/local/bin/python2.6, which may even be community-supported, but the vendor does not support it; or

(c) The vendor terminates the support contract for users who choose

     to go (b).

I think we can safely discard (c); if that is the case, the users on the said platform will not choose to update Git either, so it does not matter where the future versions of Git sets the lower bound of Python version at.

If we are not talking about the situation (c), then the users can choose to use 2.6, and more importantly, Python being a popular software, I would imagine that there are reputable sources of prepackaged RPMs for them to do so without going too much hassle of configuring, compiling and installing.

Now how does the decision we make today for releases of Git that haven't yet happened will affect these users? As these versions of newer Git were not shipped with RHEL 5.x, and also I am assuming that Git is a more niche product than Python is, I would imagine that it is very unlikely that the vendor gives it the users as an optional package. The users will have to do the same thing to be able to use such versions of Git as whatever they do in order to use Python 2.6.

Given that, what the vendor originally shipped and officially supports does not affect the choices we would make today for newer versions of Git. The users in a shop where additional third-party software in /usr/local/bin is strictly forbidden, they are stuck with the version of Git that the vendor shipped anyway, because they won't be able to install an updated Git in /usr/local/bin, either.

Quoted 8 lines

That is, unless installing 2.6 as /usr/local/bin/python2.6 (or if you are really paranoid, /usr/local/only-for-git/bin/python2.6 where nobody's $PATH points at) is impossible.

So personally I do not think dropping 2.4 is a huge problem for future versions of Git, but I'd like to hear from those working in IT support for large and slow-moving organizations (aka RHEL 5 customers).

I'm not really in the demographic that you asked to hear from, but I'll give my 2 cents anyway. :)

Firstly, I defer to those with more knowledge and experience with python to decide which version should be the minimum version supported. Python 2.6 seems to be the consensus and that's fine with me.

With respect to older platforms like RHEL 5.X that don't ship with Python 2.6 or later, I suspect most people who work in an organization with a dedicated IT staff can request that a more recent version of python be installed. So, I don't think a python 2.6 requirement (if there was one) would be a blocker for them, and I don't think it would be a major pain for the sysadmin to install.

When different version of python are used to build via distutils, the behaviour can change. Detect changes in version and pass --force in this case.

Signed-off-by John Keeping <[email protected]>

Assuming you tried this out on both 2.x and 3.x:

Acked-by Sverre Rabbelier <[email protected]>

Junio, can you replace the queued 0846b0c (git-remote-testpy: hash bytes explicitly) with this?

I hadn't realised that the "hex" encoding we chose before is a "bytes to bytes" encoding so it just fails with an error on Python 3 in the same way as the original code.

Since we want to convert a Unicode string to bytes I think UTF-8 really is the best option here.

 git-remote-testpy.py | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

git-remote-testpy.py +4 -4

index d94a66a..f8dc196 100644
@@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
 from git_remote_helpers.git.importer import GitImporter
 from git_remote_helpers.git.non_local import NonLocalGit
 
-if sys.hexversion < 0x01050200:
-    # os.makedirs() is the limiter
-    sys.stderr.write("git-remote-testgit: requires Python 1.5.2 or later.\n")
+if sys.hexversion < 0x02000000:
+    # string.encode() is the limiter
+    sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n")
     sys.exit(1)
 
 def get_repo(alias, url):

@@ -45,7 +45,7 @@ def get_repo(alias, url):
     repo.get_head()
 
     hasher = _digest()
-    hasher.update(repo.path)
+    hasher.update(repo.path.encode('utf-8'))
     repo.hash = hasher.hexdigest()
 
     repo.get_base_path = lambda base: os.path.join(

Ahh. I think it is already in "next", so this needs to be turned into an incremental to flip 'hex' to 'utf-8', with the justification being these five lines above.

Quoted 9 lines · John Keeping

Junio, can you replace the queued 0846b0c (git-remote-testpy: hash bytes explicitly) with this?

I hadn't realised that the "hex" encoding we chose before is a "bytes to bytes" encoding so it just fails with an error on Python 3 in the same way as the original code.

Since we want to convert a Unicode string to bytes I think UTF-8 really is the best option here.

Ahh. I think it is already in "next", so this needs to be turned into an incremental to flip 'hex' to 'utf-8', with the justification being these five lines above.

Thanks for catching.

Quoted 24 lines

 git-remote-testpy.py | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

git-remote-testpy.py +3 -3

index d94a66a..f8dc196 100644
@@ -31,9 +31,9 @@ from git_remote_helpers.git.exporter import GitExporter
 from git_remote_helpers.git.importer import GitImporter
 from git_remote_helpers.git.non_local import NonLocalGit
 
-if sys.hexversion < 0x01050200:
-    # os.makedirs() is the limiter
-    sys.stderr.write("git-remote-testgit: requires Python 1.5.2 or later.\n")
+if sys.hexversion < 0x02000000:
+    # string.encode() is the limiter
+    sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n")
     sys.exit(1)
 
 def get_repo(alias, url):

@@ -45,7 +45,7 @@ def get_repo(alias, url):
     repo.get_head()
 

git-remote-testpy.py def get_repo(alias, url): · line 51

Quoted 6 lines

git-remote-testpy.py +1 -1

     hasher = _digest()
-    hasher.update(repo.path)
+    hasher.update(repo.path.encode('utf-8'))
     repo.hash = hasher.hexdigest()
 
     repo.get_base_path = lambda base: os.path.join(

This will still fail under Python 2.x if repo.path is a byte string that contains non-ASCII characters. And it will fail under Python 3.1 and later if repo.path contains characters using the surrogateescape encoding option [1],...
Here you don't really need byte-for-byte correctness; it would be enough to get *some* byte string that is unique for a given input ...

Quoted 6 lines · Michael Haggerty

This will still fail under Python 2.x if repo.path is a byte string that contains non-ASCII characters. And it will fail under Python 3.1 and later if repo.path contains characters using the surrogateescape encoding option [1],...
Here you don't really need byte-for-byte correctness; it would be enough to get *some* byte string that is unique for a given input ...

Yeek.

As we do not care about the actual value at all, how about doing something like this instead?

+ hasher.update(".".join([str(ord(c)) for c in repo.path]))

So to handle all of the cases across Python versions as closely as possible to the old 2.x code, it might be necessary to make the code explicitly depend on the Python version number, like:

Quoted 3 lines · Michael Haggerty

So to handle all of the cases across Python versions as closely as possible to the old 2.x code, it might be necessary to make the code explicitly depend on the Python version number, like:

Does this all go away if we restrict ourselves to python 2.6 and just use the b prefix?

Quoted 9 lines · Junio C Hamano

Quoted 8 lines · John Keeping

git-remote-testpy.py +1 -1

@@ -45,7 +45,7 @@ def get_repo(alias, url):
     repo.get_head()
 
     hasher = _digest()
-    hasher.update(repo.path)
+    hasher.update(repo.path.encode('utf-8'))
     repo.hash = hasher.hexdigest()
 

Quoted 1 line

git-remote-testpy.py def get_repo(alias, url): · line 51

Quoted 1 line

git-remote-testpy.py +0 -0

     repo.get_base_path = lambda base: os.path.join(

This will still fail under Python 2.x if repo.path is a byte string that contains non-ASCII characters.

And it will fail under Python 3.1 and
later if repo.path contains characters using the surrogateescape encoding option [1], as it will if the original command-line argument contained bytes that cannot be decoded into Unicode using the user's default encoding:

'surrogateescape' is not supported in Python 3.0, but I think it would be quite acceptable only to support Python 3.x for x >= 1.

But 'surrogateescape' doesn't seem to be supported at all in Python 2.x (I tested 2.7.3 and it's not there).

Here you don't really need byte-for-byte correctness; it would be enough to get *some* byte string that is unique for a given input (ideally, consistent with ASCII or UTF-8 for backwards compatibility). So you could use

    b = s.encode('utf-8', 'backslashreplace')

Unfortunately, this doesn't work under Python 2.x:

    $ python2 -c "
    import sys
    print(repr(sys.argv[1]))
    print(repr(sys.argv[1].encode('utf-8', 'backslashreplace')))
    " $(echo français|iconv -t latin1)
    'fran\xe7ais'
    Traceback (most recent call last):
      File "<string>", line 4, in <module>
    UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position
4: ordinal not in range(128)

Apparently when you call bytestring.encode(), Python first tries to decode the string to Unicode using the 'ascii' encoding.

So to handle all of the cases across Python versions as closely as possible to the old 2.x code, it might be necessary to make the code explicitly depend on the Python version number, like:

hasher = _digest()
if sys.hexversion < 0x03000000:
pathbytes = repo.path
elif sys.hexversion < 0x03010000:
# If support for Python 3.0.x is desired (note: result can # be different in this case than under 2.x or 3.1+):
pathbytes = repo.path.encode(sys.getfilesystemencoding(),
'backslashreplace')
else
pathbytes = repo.path.encode(sys.getfilesystemencoding(),
'surrogateescape')
hasher.update(pathbytes)
repo.hash = hasher.hexdigest()

Quoted 4 lines · Michael Haggerty

So to handle all of the cases across Python versions as closely as possible to the old 2.x code, it might be necessary to make the code explicitly depend on the Python version number, like:

Quoted 5 lines

hasher = _digest()
if sys.hexversion < 0x03000000:
pathbytes = repo.path
elif sys.hexversion < 0x03010000:
# If support for Python 3.0.x is desired (note: result can

Quoted 8 lines

# be different in this case than under 2.x or 3.1+):
pathbytes = repo.path.encode(sys.getfilesystemencoding(),
'backslashreplace')
else
pathbytes = repo.path.encode(sys.getfilesystemencoding(),
'surrogateescape')
hasher.update(pathbytes)
repo.hash = hasher.hexdigest()

When this change was originally made (0846b0c - git-remote-testpy: hash bytes explicitly , I didn't realised that the "hex" encoding we chose is a "bytes to bytes" encoding so it just fails with an error on Python 3 in the same way as the original code.

It is not possible to provide a single code path that works on Python 2 and Python 3 since Python 2.x will attempt to decode the string before encoding it, which fails for strings that are not valid in the default encoding. Python 3.1 introduced the "surrogateescape" error handler which handles this correctly and permits a bytes -> unicode -> bytes round-trip to be lossless.

At this point Python 3.0 is unsupported so we don't go out of our way to try to support it.

Helped-by Michael Haggerty <[email protected]>

Signed-off-by John Keeping <[email protected]>

---

Quoted 5 lines · Michael Haggerty

Quoted 4 lines

So to handle all of the cases across Python versions as closely as possible to the old 2.x code, it might be necessary to make the code explicitly depend on the Python version number, like:

Quoted 13 lines

Quoted 5 lines

hasher = _digest()
if sys.hexversion < 0x03000000:
pathbytes = repo.path
elif sys.hexversion < 0x03010000:
# If support for Python 3.0.x is desired (note: result can

Quoted 8 lines

# be different in this case than under 2.x or 3.1+):
pathbytes = repo.path.encode(sys.getfilesystemencoding(),
'backslashreplace')
else
pathbytes = repo.path.encode(sys.getfilesystemencoding(),
'surrogateescape')
hasher.update(pathbytes)
repo.hash = hasher.hexdigest()

How about this?

 git-remote-testpy.py | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

git-remote-testpy.py +17 -1

index c7a04ec..16b0c52 100644
@@ -36,6 +36,22 @@ if sys.hexversion < 0x02000000:
     sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n")
     sys.exit(1)
 
+
+def _encode_filepath(path):
+    """Encodes a Unicode file path to a byte string.
+
+    On Python 2 this is a no-op; on Python 3 we encode the string as
+    suggested by [1] which allows an exact round-trip from the command line
+    to the filesystem.
+
+    [1] http://docs.python.org/3/c-api/unicode.html#file-system-encoding
+
+    """
+    if sys.hexversion < 0x03000000:
+        return path
+    return path.encode('utf-8', 'surrogateescape')
+
+
 def get_repo(alias, url):
     """Returns a git repository object initialized for usage.
     """

@@ -45,7 +61,7 @@ def get_repo(alias, url):
     repo.get_head()
 
     hasher = _digest()
-    hasher.update(repo.path.encode('hex'))
+    hasher.update(_encode_filepath(repo.path))
     repo.hash = hasher.hexdigest()
 
     repo.get_base_path = lambda base: os.path.join(

Quoted 15 lines · John Keeping

When this change was originally made (0846b0c - git-remote-testpy: hash bytes explicitly , I didn't realised that the "hex" encoding we chose is a "bytes to bytes" encoding so it just fails with an error on Python 3 in the same way as the original code.

It is not possible to provide a single code path that works on Python 2 and Python 3 since Python 2.x will attempt to decode the string before encoding it, which fails for strings that are not valid in the default encoding. Python 3.1 introduced the "surrogateescape" error handler which handles this correctly and permits a bytes -> unicode -> bytes round-trip to be lossless.

At this point Python 3.0 is unsupported so we don't go out of our way to try to support it.

Quoted 3 lines

Helped-by Michael Haggerty <[email protected]>

Signed-off-by John Keeping <[email protected]>

---

Thanks; will queue and wait for an Ack from Michael.

Does the helper function need to be named with leading underscore, though?

Quoted 4 lines

Thanks; will queue and wait for an Ack from Michael.

Does the helper function need to be named with leading underscore, though?

... Since this is a script
not a library module I don't feel strongly about it in this case.

Quoted 7 lines · John Keeping

Quoted 4 lines

Thanks; will queue and wait for an Ack from Michael.

Does the helper function need to be named with leading underscore, though?

... Since this is a script
not a library module I don't feel strongly about it in this case.

That is exactly why I asked.

Quoted 7 lines · Junio C Hamano

Quoted 5 lines · John Keeping

Quoted 4 lines

Thanks; will queue and wait for an Ack from Michael.

Does the helper function need to be named with leading underscore, though?

Quoted 4 lines

Quoted 2 lines

... Since this is a script
not a library module I don't feel strongly about it in this case.

That is exactly why I asked.

So I think the answer is "habit, but I probably shouldn't have put it in in this case".

Quoted 2 lines · John Keeping

So I think the answer is "habit, but I probably shouldn't have put it in in this case".

OK, then I'll queue with a local amend to drop the leading underscore.

I remember that I earlier asked somewhere if we want to say "Python 3.x that is older than 3.y is unsupported"

    http://thread.gmane.org/gmane.comp.version-control.git/213920/focus=213926

but I was told that we will support all versions in 3.x series, IIRC.

Does this patch contradict with that? If so I think we would need to revisit the update to CodingGuidelines in that thread.

Quoted 7 lines · Junio C Hamano

I remember that I earlier asked somewhere if we want to say "Python 3.x that is older than 3.y is unsupported"

    http://thread.gmane.org/gmane.comp.version-control.git/213920/focus=213926

but I was told that we will support all versions in 3.x series, IIRC.

Quoted 2 lines

Does this patch contradict with that? If so I think we would need to revisit the update to CodingGuidelines in that thread.

Yes. I'll send an update to that over the next couple of days.

I think 3.1 and later is fine, when I said "Python 3.0 is unsupported" in the commit message below, I meant "unsupported by the Python developers".

When this change was originally made (0846b0c - git-remote-testpy: hash bytes explicitly , I didn't realised that the "hex" encoding we chose is a "bytes to bytes" encoding so it just fails with an error on Python 3 in the same way as the original code.

It is not possible to provide a single code path that works on Python 2 and Python 3 since Python 2.x will attempt to decode the string before encoding it, which fails for strings that are not valid in the default encoding. Python 3.1 introduced the "surrogateescape" error handler which handles this correctly and permits a bytes -> unicode -> bytes round-trip to be lossless.

At this point Python 3.0 is unsupported so we don't go out of our way to try to support it.

Helped-by Michael Haggerty <[email protected]>

Signed-off-by John Keeping <[email protected]>

---

Quoted 5 lines · John Keeping

Quoted 4 lines · Michael Haggerty

So to handle all of the cases across Python versions as closely as possible to the old 2.x code, it might be necessary to make the code explicitly depend on the Python version number, like:

Quoted 13 lines

Quoted 5 lines

hasher = _digest()
if sys.hexversion < 0x03000000:
pathbytes = repo.path
elif sys.hexversion < 0x03010000:
# If support for Python 3.0.x is desired (note: result can

Quoted 8 lines

# be different in this case than under 2.x or 3.1+):
pathbytes = repo.path.encode(sys.getfilesystemencoding(),
'backslashreplace')
else
pathbytes = repo.path.encode(sys.getfilesystemencoding(),
'surrogateescape')
hasher.update(pathbytes)
repo.hash = hasher.hexdigest()

How about this?

 git-remote-testpy.py | 18 +++++++++++++++++-
 1 file changed, 17 insertions(+), 1 deletion(-)

git-remote-testpy.py +16 -0

index c7a04ec..16b0c52 100644
@@ -36,6 +36,22 @@ if sys.hexversion < 0x02000000:
     sys.stderr.write("git-remote-testgit: requires Python 2.0 or later.\n")
     sys.exit(1)
 
+
+def _encode_filepath(path):
+    """Encodes a Unicode file path to a byte string.
+
+    On Python 2 this is a no-op; on Python 3 we encode the string as
+    suggested by [1] which allows an exact round-trip from the command line
+    to the filesystem.
+
+    [1] http://docs.python.org/3/c-api/unicode.html#file-system-encoding
+
+    """
+    if sys.hexversion < 0x03000000:
+        return path
+    return path.encode('utf-8', 'surrogateescape')
+
+
 def get_repo(alias, url):
     """Returns a git repository object initialized for usage.
     """

NAK. It is still not right. If the locale is not utf-8 based, then it is incorrect to re-encode the string using utf-8. I think you really have to use sys.getfilesystemencoding() as I suggested.

---

Quoted 3 lines · Michael Haggerty

NAK. It is still not right. If the locale is not utf-8 based, then it is incorrect to re-encode the string using utf-8. I think you really have to use sys.getfilesystemencoding() as I suggested.

If you'd asked me what the patch contained I would have said it did use getfilesystemencoding(), but I can't disbelieve my own eyes :-(

Junio, please can you squash this in?

 git-remote-testpy.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

git-remote-testpy.py +1 -1

index 6098bdd..ca67899 100644
@@ -49,7 +49,7 @@ def encode_filepath(path):
     """
     if sys.hexversion < 0x03000000:
         return path
-    return path.encode('utf-8', 'surrogateescape')
+    return path.encode(sys.getfilesystemencoding(), 'surrogateescape')
 
 
 def get_repo(alias, url):