{"thread":{"id":"22079","subject":"Filename quoting / parsing problem","startedAt":"2010-01-01T17:44:23Z","lastAt":"2010-01-06T10:06:15Z","messageCount":10,"participants":["Andreas Gruenbacher","Junio C Hamano","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"130665","messageId":"201001011844.23571.agruen@suse.de","threadId":"22079","inReplyTo":null,"subject":"Filename quoting / parsing problem","fromName":"Andreas Gruenbacher","fromEmail":"agruen@suse.de","sentAt":"2010-01-01T17:44:23Z","receivedAt":"2010-01-01T17:44:23Z","isPatch":false,"sender":{"key":"agruen@suse.de","avatar":null},"body":"Git quotes file names as documented in the git-diff manual page:\n\n  TAB, LF, double quote and backslash characters in pathnames are represented\n  as \\t, \\n, \\\" and \\\\, respectively.  If there is need for such substitution\n  then the whole pathname is put in double quotes.\n\nSpaces in file names currently do not trigger quoting.  (And \\r triggers \nquoting even though the man page doesn't say so).  When there are no \"---\" and \n\"+++\" lines, this can lead to a parsing problem: only the \"diff --git\" line \ncontains the file names, sometimes with insufficient quoting.  The following \nexamples show the problem:\n\nParseable:\n    diff --git \"a/foo \\r\" \"b/foo \\r\"\n    new file mode 100644\n    index 0000000..257cc56\n    --- /dev/null\n    +++ \"b/foo \\r\"\n    @@ -0,0 +1 @@\n   +foo\n\nParseable:\n    diff --git a/bar  b/bar \n    new file mode 100644\n    index 0000000..5716ca5\n    --- /dev/null\n    +++ b/bar \n    @@ -0,0 +1 @@\n    +bar\n\nNot parseable:\n    diff --git a/baz  b/baz \n    new file mode 100644\n    index 0000000..e69de29\n\n\nCould this please be changed so that filenames with spaces are also quoted, at \nleast in the \"diff --git\" line, and possibly also in the \"---\" and \"+++\" \nlines?  Alternatively, how about a new extended header with the file name in \nthis particular case?\n\nThanks,\nAndreas\n"},{"id":"130666","messageId":"7vws01li4c.fsf@alter.siamese.dyndns.org","threadId":"22079","inReplyTo":"201001011844.23571.agruen@suse.de","subject":"Re: Filename quoting / parsing problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-01T19:50:27Z","receivedAt":"2010-01-01T19:50:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Gruenbacher <agruen@suse.de> writes:\n\n> Git quotes file names as documented in the git-diff manual page:\n>\n>   TAB, LF, double quote and backslash characters in pathnames are represented\n>   as \\t, \\n, \\\" and \\\\, respectively.  If there is need for such substitution\n>   then the whole pathname is put in double quotes.\n>\n> Spaces in file names currently do not trigger quoting.  (And \\r triggers \n> quoting even though the man page doesn't say so).\n\nAny control character is quoted; the documentation quoted above lists only\nthe common ones that have non-octal representation.\n\n        $ git init one\n        Initialized empty Git repository in /var/tmp/gomi/one/.git/\n        $ cd one\n        $ >hello && git add hello && git commit -m 'hello'\n        [master (root-commit) 5338884] hello\n         0 files changed, 0 insertions(+), 0 deletions(-)\n         create mode 100644 hello\n        $ >'a^Afile' ; >'b file' ; 'c file '\n        $ git add 'a^Afile' 'b file' 'c file '\n\nIn the above sequence that attempts to reproduce the issue, \"^A\" actually\nis a byte with value \\001 (typically you would type ^V^A to get it from\nthe terminal on the shell).  \"^G\" seems to get \"\\a\" even though it is not\nin the list (that is why I said \"only the common ones\" above).\n\n        $ git ls-files -s | cat -e\n        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0\t\"a\\001file\"$\n        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0\tb file$\n        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0\tc file $\n        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0\thello$\n\nI used \"cat -e\" to make it easier to see that \"c file \" not only has SP in\nit but it has trailing space.  Let's try the result.\n\n        $ git diff --cached | cat -e\n        diff --git \"a/a\\001file\" \"b/a\\001file\"$\n        new file mode 100644$\n        index 0000000..e69de29$\n        diff --git a/b file b/b file$\n        new file mode 100644$\n        index 0000000..e69de29$\n        diff --git a/c file  b/c file $\n        new file mode 100644$\n        index 0000000..e69de29$\n        $ git diff --cached >P.diff\n\nAnd as you described, \"b file\" and \"c file \" are not quoted and they do\nnot have ---/+++ lines.\n\nBut observe this:\n\n\t$ git reset --hard\n        $ ls\n        P.diff\thello\n\t$ git ls-files -s\n        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0\thello\n\nWe are now back in the state without any of these files, and P.diff records\na patch to recreate these three files, one with quoting and the other two\nwithout.\n\n\t$ git apply --index P.diff\n        $ git ls-files -s | cat -e\n        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0\t\"a\\001file\"$\n        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0\tb file$\n        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0\tc file $\n        100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0\thello$\n\nThis demonstrates that The claim below is false, doesn't it?\n\n> Not parseable:\n>     diff --git a/baz  b/baz \n>     new file mode 100644\n>     index 0000000..e69de29\n\nBoth \"b file\" and \"c file \" are parsed by \"git apply\" perfectly fine.\n"},{"id":"130667","messageId":"7vr5q9lhm8.fsf@alter.siamese.dyndns.org","threadId":"22079","inReplyTo":"7vws01li4c.fsf@alter.siamese.dyndns.org","subject":"Re: Filename quoting / parsing problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-01T20:01:19Z","receivedAt":"2010-01-01T20:01:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I used \"cat -e\" to make it easier to see that \"c file \" not only has SP in\n> it but it has trailing space.  Let's try the result.\n> \n>         $ git diff --cached | cat -e\n>         diff --git \"a/a\\001file\" \"b/a\\001file\"$\n>         new file mode 100644$\n>         index 0000000..e69de29$\n>         diff --git a/b file b/b file$\n>         new file mode 100644$\n>         index 0000000..e69de29$\n>         diff --git a/c file  b/c file $\n>         new file mode 100644$\n>         index 0000000..e69de29$\n>         $ git diff --cached >P.diff\n> \n> And as you described, \"b file\" and \"c file \" are not quoted and they do\n> not have ---/+++ lines.\n> \n> But observe this:\n> ...\n> We are now back in the state without any of these files, and P.diff records\n> a patch to recreate these three files, one with quoting and the other two\n> without.\n> \n>         $ git apply --index P.diff\n>         $ git ls-files -s | cat -e\n>         100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       \"a\\001file\"$\n>         100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       b file$\n>         100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       c file $\n>         100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       hello$\n> \n> This demonstrates that The claim below is false, doesn't it?\n> \n> > Not parseable:\n> >     diff --git a/baz  b/baz \n> >     new file mode 100644\n> >     index 0000000..e69de29\n> \n> Both \"b file\" and \"c file \" are parsed by \"git apply\" perfectly fine.\n\nHaving said all that, I don't think we would mind a change to treat a\npathname with trailing SP a bit specially (iow, quoting \"c file \" in the\nabove failed attempt to reproduce the issue).  A pathname with SP in it is\nan eyesore but is a fact of life outside of sane world, but a quoted\npathname is an even worse eyesore.  A pathname with trailing SP would be\nmuch less common and is more likely to be corrupted by MUA and cut & paste;\nwith quoting we can protect them a bit better.\n"},{"id":"130683","messageId":"201001021236.26947.agruen@suse.de","threadId":"22079","inReplyTo":"7vr5q9lhm8.fsf@alter.siamese.dyndns.org","subject":"Re: Filename quoting / parsing problem","fromName":"Andreas Gruenbacher","fromEmail":"agruen@suse.de","sentAt":"2010-01-02T11:36:26Z","receivedAt":"2010-01-02T11:36:26Z","isPatch":false,"sender":{"key":"agruen@suse.de","avatar":null},"body":"On Friday 01 January 2010 09:01:19 pm Junio C Hamano wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n> > I used \"cat -e\" to make it easier to see that \"c file \" not only has SP\n> > in it but it has trailing space.  Let's try the result.\n> >\n> >         $ git diff --cached | cat -e\n> >         diff --git \"a/a\\001file\" \"b/a\\001file\"$\n> >         new file mode 100644$\n> >         index 0000000..e69de29$\n> >         diff --git a/b file b/b file$\n> >         new file mode 100644$\n> >         index 0000000..e69de29$\n> >         diff --git a/c file  b/c file $\n> >         new file mode 100644$\n> >         index 0000000..e69de29$\n> >         $ git diff --cached >P.diff\n> >\n> > And as you described, \"b file\" and \"c file \" are not quoted and they do\n> > not have ---/+++ lines.\n> >\n> > But observe this:\n> > ...\n> > We are now back in the state without any of these files, and P.diff\n> > records a patch to recreate these three files, one with quoting and the\n> > other two without.\n> >\n> >         $ git apply --index P.diff\n> >         $ git ls-files -s | cat -e\n> >         100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0      \n> > \"a\\001file\"$ 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       b\n> > file$ 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       c file $\n> > 100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 0       hello$\n> >\n> > This demonstrates that The claim below is false, doesn't it?\n> >\n> > > Not parseable:\n> > >     diff --git a/baz  b/baz\n> > >     new file mode 100644\n> > >     index 0000000..e69de29\n> >\n> > Both \"b file\" and \"c file \" are parsed by \"git apply\" perfectly fine.\n\nRight, the \"diff --git\" lines are technically still parseable when the file \nname stays the same.  With renames, lines like \"diff --git a/f a/f b/f\" or \n\"diff --git a/f b/f b/f\" are possible, but then there will also be \"renamed \nfrom\" and \"renamed to\" headers which will disambiguate things.  Still, it \ndoesn't seem like a good idea to allow such ambiguities in the first place.\n\n> Having said all that, I don't think we would mind a change to treat a\n> pathname with trailing SP a bit specially (iow, quoting \"c file \" in the\n> above failed attempt to reproduce the issue).\n\nI would prefer quoting file names which contain spaces anywhere, not only at \nthe end.  If quoting helps to disambiguate a program's output, I'm all for it.  \nPeople who can't be bothered with such details can always use a pretty printer \n(side by side view, whatever).\n\nThanks,\nAndreas\n"},{"id":"130693","messageId":"7v8wcge4kr.fsf@alter.siamese.dyndns.org","threadId":"22079","inReplyTo":"201001021236.26947.agruen@suse.de","subject":"Re: Filename quoting / parsing problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-02T18:37:08Z","receivedAt":"2010-01-02T18:37:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Gruenbacher <agruen@suse.de> writes:\n\n> On Friday 01 January 2010 09:01:19 pm Junio C Hamano wrote:\n>> > Both \"b file\" and \"c file \" are parsed by \"git apply\" perfectly fine.\n>\n> Right, the \"diff --git\" lines are technically still parseable when the file \n> name stays the same.  With renames, lines like \"diff --git a/f a/f b/f\" or \n> \"diff --git a/f b/f b/f\" are possible, but then there will also be \"renamed \n> from\" and \"renamed to\" headers which will disambiguate things.  Still, it \n> doesn't seem like a good idea to allow such ambiguities in the first place.\n\nYou already realized that there is no ambiguity because \"diff --git\" lines\nare parsable and renames have explicit names.  Why do you still maintain\nthat we are allowing such \"ambiguities\" when there is none?\n\n>> Having said all that, I don't think we would mind a change to treat a\n>> pathname with trailing SP a bit specially (iow, quoting \"c file \" in the\n>> above failed attempt to reproduce the issue).\n>\n> I would prefer quoting file names which contain spaces anywhere,...\n\nThe only reason I said I don't think we would mind changing the trailing\nSP case is because the reduced risk of getting our patches corrupted by\nMUA _might_ outweigh the benefit of not quoting to avoid an eyesore [*1*].\n\nBut what you said would add to eyesore of quoted names (which you omitted\nfrom your quote) without any justification other than \"I would prefer\".\nThe pros-and-cons in such a change is quite different; as we have already\nestablished that there is no ambiguity, \"disambuguation\" is not a \"pro\" in\nthis comparison.\n\n[Footnote]\n\n*1* Strictly speaking, it is not just \"an eyesore\" that is an issue.  Our\ndiff output without renames are designed to be grokkable by other people's\npatch implementations (e.g. GNU patch), and the quoted pathnames are not\nunderstandable by them.  Even though our final version of quoted path\nformat came from the GNU diff/patch maintainer (back then, at least):\n\n    http://article.gmane.org/gmane.comp.version-control.git/10103\n\nI don't think it happened in the GNU land yet, and you would be the person\nto know about it ;-).\n"},{"id":"130705","messageId":"201001022148.47841.agruen@suse.de","threadId":"22079","inReplyTo":"7v8wcge4kr.fsf@alter.siamese.dyndns.org","subject":"Re: Filename quoting / parsing problem","fromName":"Andreas Gruenbacher","fromEmail":"agruen@suse.de","sentAt":"2010-01-02T20:48:47Z","receivedAt":"2010-01-02T20:48:47Z","isPatch":false,"sender":{"key":"agruen@suse.de","avatar":null},"body":"On Saturday 02 January 2010 07:37:08 pm Junio C Hamano wrote:\n> Andreas Gruenbacher <agruen@suse.de> writes:\n> > On Friday 01 January 2010 09:01:19 pm Junio C Hamano wrote:\n> >> > Both \"b file\" and \"c file \" are parsed by \"git apply\" perfectly fine.\n> >\n> > Right, the \"diff --git\" lines are technically still parseable when the\n> > file name stays the same.  With renames, lines like \"diff --git a/f a/f\n> > b/f\" or \"diff --git a/f b/f b/f\" are possible, but then there will also\n> > be \"renamed from\" and \"renamed to\" headers which will disambiguate\n> > things.  Still, it doesn't seem like a good idea to allow such\n> > ambiguities in the first place.\n> \n> You already realized that there is no ambiguity because \"diff --git\" lines\n> are parsable and renames have explicit names.  Why do you still maintain\n> that we are allowing such \"ambiguities\" when there is none?\n\nDon't get so aroused ...\n\nRight now, git generates lines like \"diff --git a/f a/f b/f b/f\" in some \ncorner cases, and from such lines alone, it is not possible to tell what the \ntwo file names are (either \"a/f a/f\" and \"b/f b/f\", or \"a/f a/f b/f\" and \n\"b/f\").  I can only find that out by looking at the other header lines.\n\nI would prefer a format which I can parse line by line without ambiguities in \nthe first place, because this would keep things much simpler and easier to \ndebug.  (Think of other implementations of the extended diff format which may \nnot produce the exact same output as git.)\n\nSo I would be happy with either of this:\n\n  * Also quote spaces in the \"diff --git\" line so that I can always reliably\n    parse it, or\n\n  * Add an additional extended header line with the file name in case there\n    are no other header lines giving the file names away already (as for\n    renames, copies, or when there are \"---\" and \"+++\" lines).\n\nAfter our discussion so far, option two would probably be easier for everyone: \nyou could add it without risking to break anything, and I could avoid parsing \nthe \"diff --git\" line altogether.\n\n> >> Having said all that, I don't think we would mind a change to treat a\n> >> pathname with trailing SP a bit specially (iow, quoting \"c file \" in the\n> >> above failed attempt to reproduce the issue).\n> >\n> > I would prefer quoting file names which contain spaces anywhere,...\n> \n> The only reason I said I don't think we would mind changing the trailing\n> SP case is because the reduced risk of getting our patches corrupted by\n> MUA _might_ outweigh the benefit of not quoting to avoid an eyesore [*1*].\n> \n> But what you said would add to eyesore of quoted names (which you omitted\n> from your quote) without any justification other than \"I would prefer\".\n> The pros-and-cons in such a change is quite different; as we have already\n> established that there is no ambiguity, \"disambuguation\" is not a \"pro\" in\n> this comparison.\n>\n> [Footnote]\n> \n> *1* Strictly speaking, it is not just \"an eyesore\" that is an issue.  Our\n> diff output without renames are designed to be grokkable by other people's\n> patch implementations (e.g. GNU patch), and the quoted pathnames are not\n> understandable by them.\n\nGNU patch doesn't look at \"diff --git\" lines or extended header lines at all \nso far, so there are no compatibility issues yet.  Quoting spaces in \"---\" and \n\"+++\" lines would lead to problems with current GNU patch though.  (So does \nthe quoting of several other characters like \", of course.)\n\n> Even though our final version of quoted path format came from the GNU\n> diff/patch maintainer (back then, at least):\n> \n>     http://article.gmane.org/gmane.comp.version-control.git/10103\n> \n> I don't think it happened in the GNU land yet, and you would be the person\n> to know about it ;-).\n\nI'm working on it ...\n\nThanks,\nAndreas\n"},{"id":"130874","messageId":"201001060104.25737.agruen@suse.de","threadId":"22079","inReplyTo":"201001022148.47841.agruen@suse.de","subject":"Re: Filename quoting / parsing problem","fromName":"Andreas Gruenbacher","fromEmail":"agruen@suse.de","sentAt":"2010-01-06T00:04:25Z","receivedAt":"2010-01-06T00:04:25Z","isPatch":false,"sender":{"key":"agruen@suse.de","avatar":null},"body":"On Saturday 02 January 2010 09:48:47 pm Andreas Gruenbacher wrote:\n> On Saturday 02 January 2010 07:37:08 pm Junio C Hamano wrote:\n> > I don't think it happened in the GNU land yet, and you would be the\n> > person to know about it ;-).\n> \n> I'm working on it ...\n\nThe \"experimental\" branch [*] now has very lightly tested code for parsing \nmost extended headers (\"index\", \"rename from\", \"rename to\", \"copy from\", \"copy \nto\", \"old mode\", \"new mode\", \"deleted file mode\", \"new file mode\").  Most \nthings should work, except:\n\n * Doesn't parse filenames in \"diff --git\" lines.  (I tried to argue why\n   those lines are a problem in this thread.)\n\n * sha1 checksums are not verified right now.  I'm not sure when that should\n   happen: always by default, or only optionally?  (Like verifying file modes,\n   this is going to surprise a lot of users.)\n\n * Similarity and dissimilarity headers are ignored.\n\n * Binary diffs are no supported.  I think GNU patch should recognize them and\n   give a reasonable message for now.\n\n\n[*] http://git.savannah.gnu.org/cgit/patch.git/log/?h=experimental\n\n\nCan you guys please do something to make parsing of filenames in \"diff --git\" \nlines a lot easier, or unnecessary?\n\nThanks!\nAndreas\n"},{"id":"130885","messageId":"7viqbgniq1.fsf@alter.siamese.dyndns.org","threadId":"22079","inReplyTo":"201001022148.47841.agruen@suse.de","subject":"Re: Filename quoting / parsing problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-06T01:08:06Z","receivedAt":"2010-01-06T01:08:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Gruenbacher <agruen@suse.de> writes:\n\n> Right now, git generates lines like \"diff --git a/f a/f b/f b/f\" in some \n> corner cases, and from such lines alone, it is not possible to tell what the \n> two file names are (either \"a/f a/f\" and \"b/f b/f\", or \"a/f a/f b/f\" and \n> \"b/f\").  I can only find that out by looking at the other header lines.\n\nI would understand \"a/f a/f b/f a/f\", which would be a diff of \"f a/f\"\nbetween two versions.\n\n\"a/f a/f b/f b/f\" could be rename from \"f /a/f\" to \"f b/f\" (or \"f a/f b/f\"\nto \"f\").  But you will always get \"rename from\" and \"rename to\" in that\ncase.\n\nSo you can (and I think git-apply does) follow this simple rule:\n\n    If you see +++/---/rename from/rename to/new file/deleted file, use\n    the names you find there.  Otherwise, because there is no rename,\n    \"diff --git\" lines has two identical names that follow a/ and b/, so\n    use that name.\n\nThe parsing code in builtin-apply.c is not so dense; you should be able to\nlift it from there, I think.\n\nAlthough an output of \"a/f a/f b/f b/f\" without \"rename from/to\" is\npossible with --no-index of two unrelated files, --no-index output is not\neven something that is meant to be appliable, so I wouldn't worry too much\nabout it.\n"},{"id":"130887","messageId":"7vljgcm30x.fsf@alter.siamese.dyndns.org","threadId":"22079","inReplyTo":"201001060104.25737.agruen@suse.de","subject":"Re: Filename quoting / parsing problem","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-06T01:32:30Z","receivedAt":"2010-01-06T01:32:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Gruenbacher <agruen@suse.de> writes:\n\n>  * sha1 checksums are not verified right now.  I'm not sure when that\n>  should happen: always by default, or only optionally?\n\npreimage and postimage sums are not something you would \"verify\" with\nanyway, and they are not useful unless you are dealing with binary patch,\nso I wouldn't worry too much about them.\n\n>  * Similarity and dissimilarity headers are ignored.\n\nI think it is fine to ignore them; even git doesn't use this information\nother than parroting them in \"apply --summary --stat\" output.\n\n>  * Binary diffs are no supported.  I think GNU patch should recognize\n>  them and give a reasonable message for now.\n\nNice.\n"},{"id":"131180","messageId":"m2eim3wns8.fsf@whitebox.home","threadId":"22079","inReplyTo":"7viqbgniq1.fsf@alter.siamese.dyndns.org","subject":"Re: Filename quoting / parsing problem","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2010-01-06T10:06:15Z","receivedAt":"2010-01-06T10:06:15Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> So you can (and I think git-apply does) follow this simple rule:\n>\n>     If you see +++/---/rename from/rename to/new file/deleted file, use\n>     the names you find there.  Otherwise, because there is no rename,\n>     \"diff --git\" lines has two identical names that follow a/ and b/, so\n>     use that name.\n\nIf you use diff.mnemonicprefix=true then a/ and b/ may be different.\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"}]}