git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Keeping <john@keeping.me.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: Michael Haggerty <mhagger@alum.mit.edu>,
	git@vger.kernel.org, Sverre Rabbelier <srabbelier@gmail.com>
Subject: Re: [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly
Date: Sun, 27 Jan 2013 14:21:54 +0000	[thread overview]
Message-ID: <20130127142154.GO7498@serenity.lan> (raw)
In-Reply-To: <7vy5ffxkfb.fsf@alter.siamese.dyndns.org>

On Sat, Jan 26, 2013 at 09:30:00PM -0800, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
> > 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]))

This doesn't solve the original problem since we're still ending up with
a Unicode string.  If we wanted something like this it would need to be:

    hasher.update(b'.'.join([b'%X' % ord(c) for c in repo.path]))

which limits us to Python 2.6 and later and seems to me to be less clear
than introducing an "encode_filepath" helper function using Michael's
suggestion.


John

  reply	other threads:[~2013-01-27 14:22 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-20 13:15 [PATCH v3 0/8] Python 3 support for git_remote_helpers John Keeping
2013-01-20 13:15 ` [PATCH v3 1/8] git_remote_helpers: Allow building with Python 3 John Keeping
2013-01-23 18:49   ` Sverre Rabbelier
2013-01-20 13:15 ` [PATCH v3 2/8] git_remote_helpers: fix input when running under " John Keeping
2013-01-23 19:20   ` Sverre Rabbelier
2013-01-23 19:47     ` John Keeping
2013-01-23 20:14       ` Sverre Rabbelier
2013-01-23 20:36         ` Junio C Hamano
2013-01-25 20:23           ` Brandon Casey
2013-02-05 16:07             ` Erik Faye-Lund
2013-01-20 13:15 ` [PATCH v3 3/8] git_remote_helpers: Force rebuild if python version changes John Keeping
2013-01-23 18:51   ` Sverre Rabbelier
2013-01-20 13:15 ` [PATCH v3 4/8] git_remote_helpers: Use 2to3 if building with Python 3 John Keeping
2013-01-20 13:15 ` [PATCH v3 5/8] svn-fe: allow svnrdump_sim.py to run " John Keeping
2013-01-20 13:15 ` [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly John Keeping
2013-01-26 17:51   ` John Keeping
2013-01-26 21:44     ` Junio C Hamano
2013-01-26 23:32       ` [PATCH] git-remote-testpy: fix patch hashing on Python 3 John Keeping
2013-01-27  4:44       ` [PATCH v3 6/8] git-remote-testpy: hash bytes explicitly Michael Haggerty
2013-01-27  5:30         ` Junio C Hamano
2013-01-27 14:21           ` John Keeping [this message]
2013-01-27  5:30         ` Sverre Rabbelier
2013-01-27  8:41           ` Michael Haggerty
2013-01-27 14:13         ` John Keeping
2013-01-27 14:50           ` [PATCH] git-remote-testpy: fix patch hashing on Python 3 John Keeping
2013-01-27 19:49             ` Junio C Hamano
2013-01-27 20:04               ` John Keeping
2013-01-27 20:11                 ` Junio C Hamano
2013-01-27 20:21                   ` John Keeping
2013-01-27 20:38                     ` Junio C Hamano
2013-01-27 20:47                       ` Junio C Hamano
2013-01-27 22:42                         ` John Keeping
2013-01-27 23:18                           ` Junio C Hamano
2013-01-28 10:44             ` Michael Haggerty
2013-01-28 11:20               ` [PATCH] fixup! git-remote-testpy: fix path " John Keeping
2013-01-28 17:53                 ` Junio C Hamano
2013-01-20 13:15 ` [PATCH v3 7/8] git-remote-testpy: don't do unbuffered text I/O John Keeping
2013-01-20 13:15 ` [PATCH v3 8/8] git-remote-testpy: call print as a function John Keeping

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130127142154.GO7498@serenity.lan \
    --to=john@keeping.me.uk \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=mhagger@alum.mit.edu \
    --cc=srabbelier@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).