Alex Riesen <raa.lkml@gmail.com> writes: Quote nongraphic characters in file names using alphabetic and octal backslash sequences like those used in C. This option is the same as -Q except that filenames are not surrounded by dou- ble-quotes. If you have a file whose name is 'foo' + LF + 'bar', and if you use backslash convention, your diff would start like this: diff --git a/foo\nbar b/foo\nbar @@ 1,2 3,4 @@ context -deleted ... which looks quite natural. I would, however, prefer this kind of funny pathnames to *stand* *out* more than usual, to make it really obvious that there is something really funky going on. In that sense, the above is a bit too innocuous-looking to my taste. But this "embedded LF and TAB" is a corner case. I would not be using such paths that would trigger the quoting myself anyway, and I do not particularly care as long as the tools do the right thing -- any quoting rule would do, as long as the generating side (git-diff) is consistent with accepting side (git-apply), and as long as there is no new ambiguity introduced. The backslash proposal is introducing a small ambiguity. You cannot tell if the file had an embedded LF between 'foo' and 'bar' (and generated with your git-diff) or had an embedded backslash between 'foo' and 'nbar' (and generated with existing git-diff). Since we never had a version of git-diff that outputs double-slashes '//' in paths, there is no ambiguity if we use it as a quoting mechanism. Just as a concrete demonstration, here is how the git-status output and git-diff output would look like for a file 'pqr' in a directory whose name is 'def' + LF + 'ghi' that uses the version of git-diff from the proposed updates branch: # Changed but not updated: # (use git-update-index to mark for commit) # # modified: def//{LF}//ghi/pqr diff --git a/def//{LF}//ghi/pqr b/def//{LF}//ghi/pqr index 9ee055c..47dbc3f 100644 --- a/def//{LF}//ghi/pqr +++ b/def//{LF}//ghi/pqr @@ -1 +1,2 @@ Fri Oct 7 23:19:04 PDT 2005 +foo I am not married to this quoting syntax -- I think it *is* ugly, but as I said before, I'd prefer to have something ugly here. I would easily be persuaded otherwise, though. A working patch would probably be the most effective way of persuasion, but a mock output without the code to produce and/or parse it would also be fine as a starting point for discussion. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat Oct 08 19:11:23 2005
This archive was generated by hypermail 2.1.8 : 2005-10-08 19:11:26 EST