Subject: Re: [StGIT BUG] StGIT errors out on rebasing patch deleting file with Unicode filename

From: Jakub Narebski <[email-masked]>
Date: Mon, 2 Jun 2008 17:47:34 +0200

Dnia poniedziałek 2. czerwca 2008 15:26, Catalin Marinas napisał:
> 2008/6/2 Jakub Narebski <[email-masked]>:
>> On Sun, 1 June 2008, Jakub Narebski wrote:
>>
>>> StGIT errors out on rebasing patch which deletes file with Unicode
>>> characters in filename (with characters outside US-ASCII in filename).
>>> The patch in question is patch deleting gitweb/test/* in git directory,
>>> and is present already on the 'origin' branch (the branch we rebase
>>> onto), so stg-rebase should result in an empty patch (as first patch).
>>>
>>>  "gitweb/test/M\303\244rchen" |    2 --
>>>  gitweb/test/file with spaces |    4 ----
>>>  gitweb/test/file+plus+sign   |    6 ------
>>>  3 files changed, 0 insertions(+), 12 deletions(-)
>>>  delete mode 100644 gitweb/test/Märchen
>>>  delete mode 100644 gitweb/test/file with spaces
>>>  delete mode 100644 gitweb/test/file+plus+sign
>>>
>>> I guess the error is caused by using unescaped (quoted) filename.
>>
>> You can WORKAROUND this bug by setting core.quotepath to false.  This
>> allowed me to make stg-rebase.
> 
> I can add a workaround in StGIT to actually ignore the exception
> raised by os.remove() but I don't know how to convert the quoted file
> name back to its unicode value in Python.

In Perl it is as simple as (see unquote() in gitweb/gitweb.perl)

	if ($str =~ m/^"(.*)"$/) {
		# needs unquoting
		$str = $1;
		$str =~ s/\\([^0-7]|[0-7]{1,3})/unq($1)/eg;
	}

where

	sub unq {

		#...

		if ($seq =~ m/^[0-7]{1,3}$/) {
			# octal char sequence
			return chr(oct($seq));
		} elsif (exists $es{$seq}) {
			# C escape sequence, aka character escape code
			return $es{$seq};
		}
		# quoted ordinary character
		return $seq;

Although I haven't tested this extensively.

Or you can just use '-z' switch to git-diff-tree and/or git-ls-files,
to get filename without quoting (but then you use '\0' as record
delimiter, not "\n").

-- 
Jakub Narebski
Poland