{"thread":{"id":"47334","subject":"[PATCH] git-prompt: fix reading files with windows line endings","startedAt":"2017-11-28T20:26:37Z","lastAt":"2017-12-05T23:39:43Z","messageCount":25,"participants":["Robert Abel","Johannes Schindelin","SZEDER Gábor","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"333703","messageId":"20171128201818.4132-2-rabel@robertabel.eu","threadId":"47334","inReplyTo":"20171128201818.4132-1-rabel@robertabel.eu","subject":"[PATCH] git-prompt: fix reading files with windows line endings","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-11-28T20:18:18Z","receivedAt":"2017-11-28T20:26:37Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"If any of the files read by __git_eread have \\r\\n line endings, read\nwill only strip \\n, leaving \\r. This results in an ugly prompt, where\ninstead of\n\n user@pc MINGW64 /path/to/repo (BARE:master)\n\nthe last parenthesis is printed over the beginning of the prompt like\n\n )ser@pc MINGW64 /path/to/repo (BARE:master\n\nSigned-off-by: Robert Abel \n---\n contrib/completion/git-prompt.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex c6cbef38c2..71a64e7959 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -282,7 +282,7 @@ __git_eread ()\n {\n \tlocal f=\"$1\"\n \tshift\n-\ttest -r \"$f\" && read \"$@\" <\"$f\"\n+\ttest -r \"$f\" && read \"$@\" <\"$f\" && export $@=\"${!@%$'\\r'}\"\n }\n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n-- \n2.13.0.windows.1\n\n"},{"id":"333704","messageId":"20171128201818.4132-1-rabel@robertabel.eu","threadId":"47334","inReplyTo":null,"subject":"git-prompt: fix reading files with windows line endings","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-11-28T20:18:17Z","receivedAt":"2017-11-28T20:26:38Z","isPatch":false,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"I noticed today that my git prompt using msys-git on Windows got a bit broken.\nAfter investigating I found that the git-prompt doesn't handle the case when\n__git_eread reads Windows line endings \\r\\n. It will only strip \\n, leaving\nthe \\r.\n\nI noticed this when I created a repository with msys-git, did some tasks and\nlater wanted to check the bare. Apparently, another tool on my PC went wild\nand replaced all line endings in all text files it could find, breaking my git\nprompt.\n\n"},{"id":"333779","messageId":"alpine.DEB.2.21.1.1711291519290.6482@virtualbox","threadId":"47334","inReplyTo":"20171128201818.4132-2-rabel@robertabel.eu","subject":"Re: [PATCH] git-prompt: fix reading files with windows line endings","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-29T14:27:39Z","receivedAt":"2017-11-29T14:27:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Robert,\n\nOn Tue, 28 Nov 2017, Robert Abel wrote:\n\n> If any of the files read by __git_eread have \\r\\n line endings, read\n> will only strip \\n, leaving \\r. This results in an ugly prompt, where\n> instead of\n> \n> user@pc MINGW64 /path/to/repo (BARE:master)\n> \n> the last parenthesis is printed over the beginning of the prompt like\n> \n> )ser@pc MINGW64 /path/to/repo (BARE:master\n\nThats' unfortunate, and obviously something to fix.\n\n> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> index c6cbef38c2..71a64e7959 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -282,7 +282,7 @@ __git_eread ()\n> {\n> \tlocal f=\"$1\"\n> \tshift\n> -\ttest -r \"$f\" && read \"$@\" <\"$f\"\n> +\ttest -r \"$f\" && read \"$@\" <\"$f\" && export $@=\"${!@%$'\\r'}\"\n\nAs far as I understand, $'\\r' is a Bash-only construct, and this file\n(git-prompt.sh) is targeting other Unix shells, too.\n\nSo how about using `tr -d '\\r' <\"$f\" | read \"$@\"` instead?\n\nOr maybe keep with the Bash construct, but guarded behind a test that we\narea actually running in Bash? Something like\n\n\ttest -z \"$BASH\" || IFS=$' \\t\\r\\n'\n\nCiao,\nJohannes\n"},{"id":"333816","messageId":"d57e4cb9-b0b4-314e-370a-e0db58a2a7da@robertabel.eu","threadId":"47334","inReplyTo":"alpine.DEB.2.21.1.1711291519290.6482@virtualbox","subject":"Re: [PATCH] git-prompt: fix reading files with windows line endings","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-11-29T22:09:34Z","receivedAt":"2017-11-29T22:09:41Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"Hi Johannes,\n\nOn 29 Nov 2017 15:27, Johannes Schindelin wrote:\n>> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n>> index c6cbef38c2..71a64e7959 100644\n>> --- a/contrib/completion/git-prompt.sh\n>> +++ b/contrib/completion/git-prompt.sh\n>> @@ -282,7 +282,7 @@ __git_eread ()\n>> {\n>> \tlocal f=\"$1\"\n>> \tshift\n>> -\ttest -r \"$f\" && read \"$@\" <\"$f\"\n>> +\ttest -r \"$f\" && read \"$@\" <\"$f\" && export $@=\"${!@%$'\\r'}\"\n> \n> As far as I understand, $'\\r' is a Bash-only construct, and this file\n> (git-prompt.sh) is targeting other Unix shells, too.\n\nSorry, I wasn't really aware about this bash-ism. I agree that a generic\nsolution would be best.\n\n> So how about using `tr -d '\\r' <\"$f\" | read \"$@\"` instead?\n\nThat doesn't work for me. Apparently, the variable is always reset to \"\"\nand hence the prompt will always display the shortened sha1.\nMaybe it has something to do with variable scoping inside the backtick\nevaluation?\n\n> Or maybe keep with the Bash construct, but guarded behind a test that we\n> area actually running in Bash? Something like\n> \n> \ttest -z \"$BASH\" || IFS=$' \\t\\r\\n'\n\nActually, this got me thinking and reading the POSIX.1-2008, specifically\nhttp://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html.\n\nIt seems POSIX states that IFS should be supported by read. This means\nthat it should be okay to just do\n\n> test -r \"$f\" && IFS=\" \\t\\r\\n\" read \"$@\" < \"$f\"\n\nThis would also get rid of the export and avoid introducing backtick\nevaluation.\n\nRegards,\n\nRobert\n"},{"id":"333823","messageId":"alpine.DEB.2.21.1.1711300100320.6482@virtualbox","threadId":"47334","inReplyTo":"d57e4cb9-b0b4-314e-370a-e0db58a2a7da@robertabel.eu","subject":"Re: [PATCH] git-prompt: fix reading files with windows line endings","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-30T00:21:37Z","receivedAt":"2017-11-30T00:21:45Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Robert,\n\nOn Wed, 29 Nov 2017, Robert Abel wrote:\n\n> On 29 Nov 2017 15:27, Johannes Schindelin wrote:\n>\n> > Or maybe keep with the Bash construct, but guarded behind a test that we\n> > area actually running in Bash? Something like\n> > \n> > \ttest -z \"$BASH\" || IFS=$' \\t\\r\\n'\n> \n> Actually, this got me thinking and reading the POSIX.1-2008, specifically\n> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/read.html.\n> \n> It seems POSIX states that IFS should be supported by read.\n\nYes, that's what I meant: you could use IFS.\n\n> This means that it should be okay to just do\n> \n> > test -r \"$f\" && IFS=\" \\t\\r\\n\" read \"$@\" < \"$f\"\n\nI am afraid that this won't work: when I call\n\n\tprintf '123\\r\\n' |\n\twhile IFS=\" \\t\\r\\n\" read line\n\tdo\n\t\tprintf '%s' \"$line\" |\n\t\thexdump -C\n\tdone\n\nit prints\n\n\t00000000 31 32 33 0d |123.|\n\t00000004\n\nIf I replace the double-quoted IFS by the dollar-single-quoted one, it\nworks again. I think the reason is that \\t, \\r and \\n are used literally\nwhen double-quoted, not as , and .\n\nCiao,\nJohannes\n"},{"id":"333825","messageId":"20171130010811.17369-1-szeder.dev@gmail.com","threadId":"47334","inReplyTo":"alpine.DEB.2.21.1.1711291519290.6482@virtualbox","subject":"Re: [PATCH] git-prompt: fix reading files with windows line endings","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-11-30T01:08:11Z","receivedAt":"2017-11-30T01:08:27Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"> > diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> > index c6cbef38c2..71a64e7959 100644\n> > --- a/contrib/completion/git-prompt.sh\n> > +++ b/contrib/completion/git-prompt.sh\n> > @@ -282,7 +282,7 @@ __git_eread ()\n> > {\n> > \tlocal f=\"$1\"\n> > \tshift\n> > -\ttest -r \"$f\" && read \"$@\" <\"$f\"\n> > +\ttest -r \"$f\" && read \"$@\" <\"$f\" && export $@=\"${!@%$'\\r'}\"\n\nI don't think that export is necessary here.\n\n> As far as I understand, $'\\r' is a Bash-only construct, and this file\n> (git-prompt.sh) is targeting other Unix shells, too.\n\nThe only other shell the prompt (and completion) script is targeting\nis ZSH, and ZSH understands this construct. We already use this\nconstruct to set IFS in several places in both scripts for a long\ntime, so it should be fine here, too.\n\n\nGábor\n\n"},{"id":"333828","messageId":"alpine.DEB.2.21.1.1711300250320.6482@virtualbox","threadId":"47334","inReplyTo":"20171130010811.17369-1-szeder.dev@gmail.com","subject":"Re: [PATCH] git-prompt: fix reading files with windows line endings","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-30T01:51:08Z","receivedAt":"2017-11-30T01:51:17Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Gábor,\n\nOn Thu, 30 Nov 2017, SZEDER Gábor wrote:\n\n> > > diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> > > index c6cbef38c2..71a64e7959 100644\n> > > --- a/contrib/completion/git-prompt.sh\n> > > +++ b/contrib/completion/git-prompt.sh\n> > > @@ -282,7 +282,7 @@ __git_eread ()\n> > > {\n> > > \tlocal f=\"$1\"\n> > > \tshift\n> > > -\ttest -r \"$f\" && read \"$@\" <\"$f\"\n> > > +\ttest -r \"$f\" && read \"$@\" <\"$f\" && export $@=\"${!@%$'\\r'}\"\n> \n> I don't think that export is necessary here.\n> \n> > As far as I understand, $'\\r' is a Bash-only construct, and this file\n> > (git-prompt.sh) is targeting other Unix shells, too.\n> \n> The only other shell the prompt (and completion) script is targeting\n> is ZSH, and ZSH understands this construct. We already use this\n> construct to set IFS in several places in both scripts for a long\n> time, so it should be fine here, too.\n\nThat's good to know! I should have `git grep`ped...\n\nSorry for the noise,\nJohannes"},{"id":"333835","messageId":"cacbf41e-3b4a-99e2-a0e0-50bb4cd9e152@robertabel.eu","threadId":"47334","inReplyTo":"alpine.DEB.2.21.1.1711300100320.6482@virtualbox","subject":"Re: [PATCH] git-prompt: fix reading files with windows line endings","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-11-30T06:22:04Z","receivedAt":"2017-11-30T06:22:14Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"Hi Johannes,\n\nOn 30 Nov 2017 01:21, Johannes Schindelin wrote:\n> On Wed, 29 Nov 2017, Robert Abel wrote:\n>> This means that it should be okay to just do\n>>\n>>> test -r \"$f\" && IFS=\" \\t\\r\\n\" read \"$@\" < \"$f\"\n> \n> I am afraid that this won't work: when I call\n\nI managed to trick myself with that one, yes...\nApparently I had already converted my HEAD back to Unix line endings.\n\nHowever, I noticed that the behavior of read is apparently\nambiguous for the last (or a single) variable:\n\nFrom POSIX.1-2008:\n> If there are fewer vars than fields, the last var shall be set to a\n> value comprising the following elements:\n> - The field that corresponds to the last var in the normal assignment\n> sequence described above\n> - The delimiter(s) that follow the field corresponding to the last var\n> - The remaining fields and their delimiters, with trailing IFS white\n> space ignored\n\nI read that last \"ignored\" as \"trailing IFS white space shall not be\nappended\". Apparently, people implementing read read it as \"trailing\nIFS while space shall not be processed further\"\n\nThus, the behavior for trailing IFS white space is different in\ncase of one or two variables:\n\n printf '123 456\\r\\n' | while IFS=$' \\t\\r\\n' read foo bar\n do\n printf 'foo: %s' \"$foo\" | hexdump -C\n printf 'bar: %s' \"$bar\" | hexdump -C\n done\n\nThis works as expected trimming the trailing \\r:\n 00000000 66 6f 6f 3a 20 31 32 33 |foo: 123|\n 00000008\n 00000000 62 61 72 3a 20 34 35 36 |bar: 456|\n 00000008\n\nWhile doing the same just reading a single variable\n\n printf '123 456\\r\\n' | while IFS=$' \\t\\r\\n' read foo\n do\n printf 'foo: %s' \"$foo\" | hexdump -C\n printf 'bar: %s' \"$bar\" | hexdump -C\n done\n\nprints\n\n 00000000 66 6f 6f 3a 20 31 32 33 20 34 35 36 0d |foo:\n123 456.|\n 0000000d\n 00000000 62 61 72 3a 20 |bar: |\n 00000005\n\nNotice the 0d at the end of foo, which didn't get trimmed.\n\nSo reading a dummy variable along with the actual content variable\nworks for git-prompt:\n\n __git_eread ()\n {\n local f=\"$1\"\n local dummy\n shift\n test -r \"$f\" && IFS=$'\\r\\n' read \"$@\" dummy < \"$f\"\n }\n\nI feel like this would be the most readable solution thus far.\n\nRegards,\n\nRobert\n"},{"id":"333854","messageId":"alpine.DEB.2.21.1.1711301619590.6482@virtualbox","threadId":"47334","inReplyTo":"cacbf41e-3b4a-99e2-a0e0-50bb4cd9e152@robertabel.eu","subject":"Re: [PATCH] git-prompt: fix reading files with windows line endings","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-11-30T15:21:22Z","receivedAt":"2017-11-30T15:21:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Robert,\n\nOn Thu, 30 Nov 2017, Robert Abel wrote:\n\n> So reading a dummy variable along with the actual content variable\n> works for git-prompt:\n> \n> __git_eread ()\n> {\n> local f=\"$1\"\n> local dummy\n> shift\n> test -r \"$f\" && IFS=$'\\r\\n' read \"$@\" dummy < \"$f\"\n> }\n> \n> I feel like this would be the most readable solution thus far.\n\nHmm. I am just a little concerned about \"dummy\" swallowing the rest of the\nline, e.g. when reading \"1 2 3\" via `__git_eread line`... the way I read\nit, dummy would consume \"2 3\" and line would *not* receive \"1 2 3\" but\nonly \"1\"...\n\nCiao,\nJohannes\n"},{"id":"333862","messageId":"3557a15f-3019-7d31-b990-66c2e0cb893f@robertabel.eu","threadId":"47334","inReplyTo":"alpine.DEB.2.21.1.1711301619590.6482@virtualbox","subject":"Re: [PATCH] git-prompt: fix reading files with windows line endings","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-11-30T18:01:49Z","receivedAt":"2017-11-30T18:01:54Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"Hi Johannes,\n\nOn 30 Nov 2017 16:21, Johannes Schindelin wrote:\n> On Thu, 30 Nov 2017, Robert Abel wrote:\n>> So reading a dummy variable along with the actual content variable\n>> works for git-prompt:\n>>\n>> __git_eread ()\n>> {\n>> local f=\"$1\"\n>> local dummy\n>> shift\n>> test -r \"$f\" && IFS=$'\\r\\n' read \"$@\" dummy < \"$f\"\n>> }\n>>\n>> I feel like this would be the most readable solution thus far.\n> \n> Hmm. I am just a little concerned about \"dummy\" swallowing the rest of the\n> line, e.g. when reading \"1 2 3\" via `__git_eread line`... the way I read\n> it, dummy would consume \"2 3\" and line would *not* receive \"1 2 3\" but\n> only \"1\"...\nYou missed that tab and space aren't field separator anymore,\nbecause IFS=$'\\r\\n'. The way I see it, __git_eread was never meant to\nsplit tokens. Its primary purpose was to test if a file exists and if\nso, read all its contents sans the newline into a variable.\n\nThat's how all call to __git_eread use it. And none of them are equipped\nto handle multi-line file contents or want to read more than one variable.\n\nSo this version does exactly that, but for CRLF line endings, too.\nI successfully use the above version now on two of my PCs.\n\nIf you agree and nobody else has any concerns, I'll resend an edited\npatch to accomodate for the changes and probably put a comment with\nusage info above __git_eread.\n\nRegards,\n\nRobert\n\n\n"},{"id":"333878","messageId":"CAM0VKjnpUNhMJk6wk1prtvr2SjOuhMLKWQ7zf8S6w-0yfD5WcQ@mail.gmail.com","threadId":"47334","inReplyTo":"alpine.DEB.2.21.1.1711300250320.6482@virtualbox","subject":"Re: [PATCH] git-prompt: fix reading files with windows line endings","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2017-11-30T23:45:45Z","receivedAt":"2017-11-30T23:45:51Z","isPatch":true,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Thu, Nov 30, 2017 at 2:51 AM, Johannes Schindelin\n wrote:\n> On Thu, 30 Nov 2017, SZEDER Gábor wrote:\n>\n>> > > diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n>> > > index c6cbef38c2..71a64e7959 100644\n>> > > --- a/contrib/completion/git-prompt.sh\n>> > > +++ b/contrib/completion/git-prompt.sh\n>> > > @@ -282,7 +282,7 @@ __git_eread ()\n>> > > {\n>> > > local f=\"$1\"\n>> > > shift\n>> > > - test -r \"$f\" && read \"$@\" <\"$f\"\n>> > > + test -r \"$f\" && read \"$@\" <\"$f\" && export $@=\"${!@%$'\\r'}\"\n>>\n>> I don't think that export is necessary here.\n>>\n>> > As far as I understand, $'\\r' is a Bash-only construct, and this file\n>> > (git-prompt.sh) is targeting other Unix shells, too.\n>>\n>> The only other shell the prompt (and completion) script is targeting\n>> is ZSH, and ZSH understands this construct. We already use this\n>> construct to set IFS in several places in both scripts for a long\n>> time, so it should be fine here, too.\n>\n> That's good to know! I should have `git grep`ped...\n>\n> Sorry for the noise,\n\nNo, no, your concern is justified, you just happened to pick the wrong\nconstruct :)\n\nIt's the ${!var} indirect expansion construct that ZSH doesn't know, it\nuses a different syntax for that.\n\n\nGábor\n"},{"id":"333903","messageId":"alpine.DEB.2.21.1.1712011143320.98586@virtualbox","threadId":"47334","inReplyTo":"3557a15f-3019-7d31-b990-66c2e0cb893f@robertabel.eu","subject":"Re: [PATCH] git-prompt: fix reading files with windows line endings","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-12-01T10:45:45Z","receivedAt":"2017-12-01T10:45:54Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Robert,\n\nOn Thu, 30 Nov 2017, Robert Abel wrote:\n\n> On 30 Nov 2017 16:21, Johannes Schindelin wrote:\n> > On Thu, 30 Nov 2017, Robert Abel wrote:\n> >> So reading a dummy variable along with the actual content variable\n> >> works for git-prompt:\n> >>\n> >> __git_eread ()\n> >> {\n> >> local f=\"$1\"\n> >> local dummy\n> >> shift\n> >> test -r \"$f\" && IFS=$'\\r\\n' read \"$@\" dummy < \"$f\"\n> >> }\n> >>\n> >> I feel like this would be the most readable solution thus far.\n> > \n> > Hmm. I am just a little concerned about \"dummy\" swallowing the rest of the\n> > line, e.g. when reading \"1 2 3\" via `__git_eread line`... the way I read\n> > it, dummy would consume \"2 3\" and line would *not* receive \"1 2 3\" but\n> > only \"1\"...\n> You missed that tab and space aren't field separator anymore,\n> because IFS=$'\\r\\n'. The way I see it, __git_eread was never meant to\n> split tokens. Its primary purpose was to test if a file exists and if\n> so, read all its contents sans the newline into a variable.\n\nAh. The \"$@* put me on the wrong track. If you hard-code the expectation\nthat __git_eread is not used to split tokens, maybe there should be a\npreparatory patch (after carefully ensuring that all callers pass only one\nargument) to change the \"$@\" to \"$1\"?\n\nThat will prevent future callers from expecting the token-splitting\nbehavior that is promised by using \"$@\".\n\nCiao,\nJohannes\n"},{"id":"333945","messageId":"20171201233133.30011-1-rabel@robertabel.eu","threadId":"47334","inReplyTo":"alpine.DEB.2.21.1.1712011143320.98586@virtualbox","subject":"[PATCH v2 1/2] git-prompt: make __git_eread intended use explicit","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-12-01T23:31:32Z","receivedAt":"2017-12-01T23:30:08Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"__git_eread is used to read a single line of a given file (if it exists)\ninto a variable without the EOL. All six current users of __git_eread\nuse it that way and don't expect multi-line content.\n\nThus, add a comment and explicitly use $2 instead of shifting the args\ndown and using $@.\n\nSigned-off-by: Robert Abel \n---\n contrib/completion/git-prompt.sh | 7 ++++---\n 1 file changed, 4 insertions(+), 3 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex c6cbef38c..41a471957 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -278,11 +278,12 @@ __git_ps1_colorize_gitstring ()\n \tr=\"$c_clear$r\"\n }\n \n+# Helper function to read the first line of a file into a variable.\n+# __git_eread requires 2 arguments, the file path and the name of the\n+# variable, in that order.\n __git_eread ()\n {\n-\tlocal f=\"$1\"\n-\tshift\n-\ttest -r \"$f\" && read \"$@\" <\"$f\"\n+\ttest -r \"$1\" && read \"$2\" <\"$1\"\n }\n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n-- \n2.15.1\n\n"},{"id":"333946","messageId":"20171201233133.30011-2-rabel@robertabel.eu","threadId":"47334","inReplyTo":"20171201233133.30011-1-rabel@robertabel.eu","subject":"[PATCH v2 2/2] git-prompt: fix reading files with windows line endings","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-12-01T23:31:33Z","receivedAt":"2017-12-01T23:30:24Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"If any of the files read by __git_eread have \\r\\n line endings, read\nwill only strip \\n, leaving \\r. This results in an ugly prompt, where\ninstead of\n\n user@pc MINGW64 /path/to/repo (BARE:master)\n\nthe last parenthesis is printed over the beginning of the prompt like\n\n )ser@pc MINGW64 /path/to/repo (BARE:master\n\nSigned-off-by: Robert Abel \n---\n contrib/completion/git-prompt.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 41a471957..983e419d2 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -283,7 +283,7 @@ __git_ps1_colorize_gitstring ()\n # variable, in that order.\n __git_eread ()\n {\n-\ttest -r \"$1\" && read \"$2\" <\"$1\"\n+\ttest -r \"$1\" && IFS=$'\\r\\n' read \"$2\" <\"$1\"\n }\n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n-- \n2.15.1\n\n"},{"id":"334048","messageId":"alpine.DEB.2.21.1.1712041516280.98586@virtualbox","threadId":"47334","inReplyTo":"20171201233133.30011-2-rabel@robertabel.eu","subject":"Re: [PATCH v2 2/2] git-prompt: fix reading files with windows line endings","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-12-04T14:18:25Z","receivedAt":"2017-12-04T14:18:36Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Robert,\n\n1/2 looks very good.\n\nOn Sat, 2 Dec 2017, Robert Abel wrote:\n\n> If any of the files read by __git_eread have \\r\\n line endings, read\n> will only strip \\n, leaving \\r. This results in an ugly prompt, where\n> instead of\n> \n> user@pc MINGW64 /path/to/repo (BARE:master)\n> \n> the last parenthesis is printed over the beginning of the prompt like\n> \n> )ser@pc MINGW64 /path/to/repo (BARE:master\n\nMaybe mention explicitly what Gabór said about $'...' being supported by\nBash and zsh, the only two intended users of git-prompt.sh (and there\nbeing precedent of that construct being used already e.g. in __git_ps1)?\n\nOther than that, this looks very good to me.\n\nThanks,\nJohannes"},{"id":"334074","messageId":"xmqqindmml25.fsf@gitster.mtv.corp.google.com","threadId":"47334","inReplyTo":"20171201233133.30011-1-rabel@robertabel.eu","subject":"Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-12-04T17:58:58Z","receivedAt":"2017-12-04T17:59:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robert Abel writes:\n\n> __git_eread is used to read a single line of a given file (if it exists)\n> into a variable without the EOL. All six current users of __git_eread\n> use it that way and don't expect multi-line content.\n\nChanging $@ to $2 does not change whether this is about \"multi-line\"\nor not. What you are changing is that the original was prepared to\nbe given two or more variable names, and split an input line at IFS\ninto multiple tokens to be assigned to these variables, but with\nthis change, the caller can only use one variable and this function\nwill not split the line and store it into that single variable.\n\nThe above can easily be fixed with a bit of rewording, perhaps like:\n\n ... that way. We do not need to split the line into tokens and\n assign them to multiple variables---reading only into a single\n variable needs to be supported.\n\nWhile reviewing this patch, I also wondered if the \"read\" wants to\nbecome \"read -r\" or something that is even safer than simply\navoiding tokenization, but after scanning to see exactly which files\n__git_eread is used to read from, I do not think it matters (the\ninput will not have a backslash that would want to be protected from\n'read'), so this should be OK.\n\n> Signed-off-by: Robert Abel \n> ---\n> contrib/completion/git-prompt.sh | 7 ++++---\n> 1 file changed, 4 insertions(+), 3 deletions(-)\n>\n> diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\n> index c6cbef38c..41a471957 100644\n> --- a/contrib/completion/git-prompt.sh\n> +++ b/contrib/completion/git-prompt.sh\n> @@ -278,11 +278,12 @@ __git_ps1_colorize_gitstring ()\n> \tr=\"$c_clear$r\"\n> }\n> \n> +# Helper function to read the first line of a file into a variable.\n> +# __git_eread requires 2 arguments, the file path and the name of the\n> +# variable, in that order.\n> __git_eread ()\n> {\n> -\tlocal f=\"$1\"\n> -\tshift\n> -\ttest -r \"$f\" && read \"$@\" <\"$f\"\n> +\ttest -r \"$1\" && read \"$2\" <\"$1\"\n> }\n> \n> # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n"},{"id":"334105","messageId":"e8d35c35-ffd5-ef10-bc6a-0834c1703995@robertabel.eu","threadId":"47334","inReplyTo":"xmqqindmml25.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-12-04T22:57:36Z","receivedAt":"2017-12-04T22:57:43Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"Hi Junio,\n\nOn 04 Dec 2017 18:58, Junio C Hamano wrote:\n> Robert Abel writes:\n>> __git_eread is used to read a single line of a given file (if it exists)\n>> into a variable without the EOL. All six current users of __git_eread\n>> use it that way and don't expect multi-line content.\n> \n> Changing $@ to $2 does not change whether this is about \"multi-line\"\n> or not. \n\nI'm aware of that. I was documenting current usage. The function is used\nto read file contents (which are expected to be a single line) into\n_a_ (i.e. single) variable.\n\nNone of the current users of the function expect tokens to be split,\nwhich is why I removed it in preparation of patch 2/2, which would\nbreak tokenizing file contents.\n\nRegards,\n\nRobert\n"},{"id":"334109","messageId":"20171204234923.9600-1-rabel@robertabel.eu","threadId":"47334","inReplyTo":"20171201233133.30011-1-rabel@robertabel.eu","subject":"[PATCH v3 1/2] git-prompt: make __git_eread intended use explicit","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-12-04T23:49:22Z","receivedAt":"2017-12-04T23:49:51Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"__git_eread is used to read a single line of a given file (if it exists)\ninto a single variable without the EOL. All six current users of __git_eread\nuse it that way and don't expect multi-line content.\n\nTherefore, this patch removes the unused capability to split file conents into\ntokens by passing multiple variable names. Add a comment and explicitly use $2\ninstead of $@ to read the file into one variable.\n\nSigned-off-by: Robert Abel \n---\n contrib/completion/git-prompt.sh | 7 ++++---\n 1 file changed, 4 insertions(+), 3 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex c6cbef38c2..41a471957a 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -278,11 +278,12 @@ __git_ps1_colorize_gitstring ()\n \tr=\"$c_clear$r\"\n }\n \n+# Helper function to read the first line of a file into a variable.\n+# __git_eread requires 2 arguments, the file path and the name of the\n+# variable, in that order.\n __git_eread ()\n {\n-\tlocal f=\"$1\"\n-\tshift\n-\ttest -r \"$f\" && read \"$@\" <\"$f\"\n+\ttest -r \"$1\" && read \"$2\" <\"$1\"\n }\n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n-- \n2.13.0.windows.1\n\n"},{"id":"334110","messageId":"20171204234923.9600-2-rabel@robertabel.eu","threadId":"47334","inReplyTo":"20171204234923.9600-1-rabel@robertabel.eu","subject":"[PATCH v3 2/2] git-prompt: fix reading files with windows line endings","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-12-04T23:49:23Z","receivedAt":"2017-12-04T23:49:55Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"If any of the files read by __git_eread have \\r\\n line endings, read\nwill only strip \\n, leaving \\r. This results in an ugly prompt, where\ninstead of\n\n user@pc MINGW64 /path/to/repo (BARE:master)\n\nthe last parenthesis is printed over the beginning of the prompt like\n\n )ser@pc MINGW64 /path/to/repo (BARE:master\n\nThis patch fixes the issue by setting the IFS to $'\\r\\n' for the read\noperation. Note that ANSI-C Quoting ($'...') is supported by bash as\nwell as zsh, which are the current targets of git-prompt.sh, cf.\n<20171130010811.17369-1-szeder.dev@gmail.com>.\n\nSigned-off-by: Robert Abel \n---\n contrib/completion/git-prompt.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 41a471957a..983e419d2b 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -283,7 +283,7 @@ __git_ps1_colorize_gitstring ()\n # variable, in that order.\n __git_eread ()\n {\n-\ttest -r \"$1\" && read \"$2\" <\"$1\"\n+\ttest -r \"$1\" && IFS=$'\\r\\n' read \"$2\" <\"$1\"\n }\n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n-- \n2.13.0.windows.1\n\n"},{"id":"334129","messageId":"xmqqd13ukohs.fsf@gitster.mtv.corp.google.com","threadId":"47334","inReplyTo":"e8d35c35-ffd5-ef10-bc6a-0834c1703995@robertabel.eu","subject":"Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-12-05T00:27:43Z","receivedAt":"2017-12-05T00:27:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robert Abel writes:\n\n> Hi Junio,\n>\n> On 04 Dec 2017 18:58, Junio C Hamano wrote:\n>> Robert Abel writes:\n>>> __git_eread is used to read a single line of a given file (if it exists)\n>>> into a variable without the EOL. All six current users of __git_eread\n>>> use it that way and don't expect multi-line content.\n>> \n>> Changing $@ to $2 does not change whether this is about \"multi-line\"\n>> or not. \n>\n> I'm aware of that. I was documenting current usage. The function is used\n> to read file contents (which are expected to be a single line) into\n> _a_ (i.e. single) variable.\n>\n> None of the current users of the function expect tokens to be split,\n> which is why I removed it in preparation of patch 2/2, which would\n> break tokenizing file contents.\n\nI know all of the above, but I think you misunderstood the point I\nwanted to raise, so let me try again. The thing is, none of what\nyou just wrote changes the fact that lack of callers that want to do\n\"multi-line\" is IRRELEVANT. True, there is no caller that wants to\nread multiple lines---it is a true statement, but it is irrelevant\nstatement. On the other hand, it is true and relevant that no\ncaller expects to split a line into multiple variables.\n\nBy changing \"$@\" to \"$2\" there, you would have broken callers that\nwanted the helper function to read into multiple variables (if there\nwere such callers). Explaining the current usage that nobody does\nso *IS* a valid justification for the change. It is relevant.\n\nWith or without that change, a caller that wanted to read multiple\nlines from the file would never have worked. It was just doing a\nsingle \"read\" built-in, so the only thing that would have been\nworked on is the first line of the file. Your change wouldn't have\nchanged that---if a caller wanted to peek into the second line, your\nchange wouldn't have helped such a caller. And it is not like your\nchange would have broken such a caller that were happily reading the\nsecond and subsequent line. The original wouldn't allowed it to\nread the second line anyway.\n\nContrasting this with the above obsesrvation about possible breakage\nfor multi-variable callers (if there were such callers---luckily\nthere wasn't any), I hope that you can see why the lack of\n\"multi-line\" caller in the existing usage is totally irrelevant when\nanalyzing this change and explaining why this is a good change.\n\nHTH.\n"},{"id":"334138","messageId":"818f414b-76ab-6e1d-0c5c-7f9959223e64@robertabel.eu","threadId":"47334","inReplyTo":"xmqqd13ukohs.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-12-05T07:01:41Z","receivedAt":"2017-12-05T07:02:02Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"Hi Junio,\n\nOn 05 Dec 2017 01:27, Junio C Hamano wrote:\n> I know all of the above, but I think you misunderstood the point I\n> wanted to raise, so let me try again. The thing is, none of what\n> you just wrote changes the fact that lack of callers that want to do\n> \"multi-line\" is IRRELEVANT.\n\nI disagree. The commit comment is meant to give context to the\nintroduced changes. One change is the additional comment for\n__git_eread, which now clearly states that only a single line is read.\n\nI'm well aware that I'm not breaking reading multiple lines, because\nthat never worked in the first place. Thus, it was never the indented\nuse for __git_eread as I see it. I explicitly want to include that\ninformation in my commit message to pay it forward to the next person\nworking on the prompt.\n\nRegards,\n\nRobert\n"},{"id":"334151","messageId":"xmqqlgihjpd6.fsf@gitster.mtv.corp.google.com","threadId":"47334","inReplyTo":"818f414b-76ab-6e1d-0c5c-7f9959223e64@robertabel.eu","subject":"Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-12-05T13:06:29Z","receivedAt":"2017-12-05T13:06:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robert Abel writes:\n\n> On 05 Dec 2017 01:27, Junio C Hamano wrote:\n>> I know all of the above, but I think you misunderstood the point I\n>> wanted to raise, so let me try again. The thing is, none of what\n>> you just wrote changes the fact that lack of callers that want to do\n>> \"multi-line\" is IRRELEVANT.\n>\n> I disagree. The commit comment is meant to give context to the\n> introduced changes. One change is the additional comment for\n> __git_eread, which now clearly states that only a single line is read.\n\nI still do not understand why you think the 'next' person would care\nabout the (lack of )multi-line aspect of the helper.\n\nLet's see how well the proposed log message gives the \"context to\nthe introduced changes\" (from your v3).\n\n __git_eread is used to read a single line of a given file (if it\n exists) into a single variable without the EOL. All six current\n users of __git_eread use it that way and don't expect multi-line\n content.\n\nThat does not include anything incorrect; but.\n\nThe helper is about (1) reading the first line and (2) reading it as\na whole into a single variable. Both are already covered by the\nfirst sentence, and there is no need to say 'and don't expect ...\",\nunless you want to stress something.\n\nAnd it places a stress on the former, which is a less relevant\nthing, WITHOUT giving the same treatment to the latter, which is a\nmore relevant thing. After all, this patch is not about replacing\nan earlier implementation that did\n\n $2=$(cat \"$1\")\n\nwith\n\n read $2 <\"$1\"\n\nIf that were the case, _then_ the fact that the purpose of the\nhelper is to read from a single-liner file (i.e. we do not expect\nthe input file to have more than one line) is VERY relevant.\n\nBut this is not such a patch. And after readers read the above,\nthey find this:\n\n Therefore, this patch removes the unused capability to split\n file conents into tokens by passing multiple variable names.\n\nAnd because the previous paragraph placed an emphasis on a wrong\naspect of the context of the calls to the helper function, this\n\"Therefore\" does not quite \"click\" in the readers' minds. The\nreason why it is OK to remove the multi-variable feature is because\nthe callers of the helper want to always read the result into a\nsingle variable, but the \"no need for multi-variable\" that they read\nin the first sentence of the previous paragraph is less strong in\ntheir mind by now, because they read an irrelevant (for the purpose\nof this \"Therefore\") mention of \"no need for multi-line\" aspect of\nthe helper.\n\nPerhaps\n\n __git_eread is used to read the contents of a single-liner file\n into a single variable while dropping EOL. It is misleading to\n use the \"read\" built-in with \"$@\", as if some callers would want\n the contents read from the file to be split into multiple\n variables.\n\n Explicitly use a single variable, and also document that the\n helper only reads the first line (simply because the input files\n are designed to be single-liner files).\n\nwould say it the same thing, but with emphasis on the right aspect\nof the facts.\n\nI would also rephase the new in-code comment\n\n # Helper function to read the first line of a file into a variable.\n\nto un-stress \"the first line of a file\" and place more stress on the\nfact that it is designed to read from a single-liner file (there is\na subtle but important distinction between the two).\n\n # read the contents of a single-liner file into a variable,\n # while dropping the end-of-line from it.\n\nor something like that, perhaps.\n\n\n"},{"id":"334234","messageId":"23f95ab7-4ece-5252-5bae-16eec8f34824@robertabel.eu","threadId":"47334","inReplyTo":"xmqqlgihjpd6.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH v2 1/2] git-prompt: make __git_eread intended use explicit","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-12-05T23:37:20Z","receivedAt":"2017-12-05T23:37:27Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"Dear Junio,\n\nI'm amazed at how much time and energy you spend on correcting these\nessentially non-issues in my git commit messages for a quadruple-liner\ncode change.\n\nI'll resend both patches one last time addressing the grave issue of the\ninformative mention of multi-line files.\n\nRegards,\n\nRobert\n"},{"id":"334235","messageId":"20171205233912.5824-1-rabel@robertabel.eu","threadId":"47334","inReplyTo":"23f95ab7-4ece-5252-5bae-16eec8f34824@robertabel.eu","subject":"[PATCH v4 1/2] git-prompt: make __git_eread intended use explicit","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-12-05T23:39:11Z","receivedAt":"2017-12-05T23:39:35Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"__git_eread is used to read a single line of a given file (if it exists)\ninto a single variable stripping the EOL.\nThis patch removes the unused capability to split file contents into tokens\nby passing multiple variable names. Add a comment and explicitly use $2\ninstead of misleading $@ as argument to the read builtin command.\n\nSigned-off-by: Robert Abel \n---\n contrib/completion/git-prompt.sh | 7 ++++---\n 1 file changed, 4 insertions(+), 3 deletions(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex c6cbef38c2..41a471957a 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -278,11 +278,12 @@ __git_ps1_colorize_gitstring ()\n \tr=\"$c_clear$r\"\n }\n \n+# Helper function to read the first line of a file into a variable.\n+# __git_eread requires 2 arguments, the file path and the name of the\n+# variable, in that order.\n __git_eread ()\n {\n-\tlocal f=\"$1\"\n-\tshift\n-\ttest -r \"$f\" && read \"$@\" <\"$f\"\n+\ttest -r \"$1\" && read \"$2\" <\"$1\"\n }\n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n-- \n2.13.0.windows.1\n\n"},{"id":"334236","messageId":"20171205233912.5824-2-rabel@robertabel.eu","threadId":"47334","inReplyTo":"20171205233912.5824-1-rabel@robertabel.eu","subject":"[PATCH v4 2/2] git-prompt: fix reading files with windows line endings","fromName":"Robert Abel","fromEmail":"rabel@robertabel.eu","sentAt":"2017-12-05T23:39:12Z","receivedAt":"2017-12-05T23:39:43Z","isPatch":true,"sender":{"key":"rabel@robertabel.eu","avatar":"https://avatars.githubusercontent.com/u/9909021?v=4"},"body":"If any of the files read by __git_eread have \\r\\n line endings, read\nwill only strip \\n, leaving \\r. This results in an ugly prompt, where\ninstead of\n\n user@pc MINGW64 /path/to/repo (BARE:master)\n\nthe last parenthesis is printed over the beginning of the prompt like\n\n )ser@pc MINGW64 /path/to/repo (BARE:master\n\nThis patch fixes the issue by changing the internal field separator\nvariable IFS to $'\\r\\n' before using the read builtin command.\n\nNote that ANSI-C Quoting/POSIX Quoting ($'...') is supported by bash\nas well as zsh, which are the current targets of git-prompt, cf.\ncontrib/completion/git-prompt.sh.\n\nSigned-off-by: Robert Abel \n---\n contrib/completion/git-prompt.sh | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh\nindex 41a471957a..983e419d2b 100644\n--- a/contrib/completion/git-prompt.sh\n+++ b/contrib/completion/git-prompt.sh\n@@ -283,7 +283,7 @@ __git_ps1_colorize_gitstring ()\n # variable, in that order.\n __git_eread ()\n {\n-\ttest -r \"$1\" && read \"$2\" <\"$1\"\n+\ttest -r \"$1\" && IFS=$'\\r\\n' read \"$2\" <\"$1\"\n }\n \n # __git_ps1 accepts 0 or 1 arguments (i.e., format string)\n-- \n2.13.0.windows.1\n\n"}]}