# Bug: pull --rebase with é in name 17 messages from 2012-03-05 to 2012-03-06. Participants: René Haber, Jeff King, Thomas Rast, Jakub Narebski, Junio C Hamano. Thread: https://gitlist.dev/t/29834 ## René Haber, 2012-03-05 09:59 Subject: Bug: pull --rebase with é in name Message-ID: URL: https://gitlist.dev/e/FECFDD4D-6EC3-4DE1-8A08-B4477345C4AA%40habr.de ``` Hello, I'm having trouble with the following scenario: My name contains an é with accent. Having set git config --global user.name "René Haber" and several commits with that name in a project. Now I wanted to pull with --rebase, which fails with: git pull --rebase remote: Counting objects: 9, done. remote: Compressing objects: 100% (5/5), done. remote: Total 5 (delta 4), reused 0 (delta 0) Unpacking objects: 100% (5/5), done. From ____.de:repositories/kapa 173c610..18987db master -> origin/master First, rewinding head to replay your work on top of it... /sw/lib/git-core/git-am: line 675: Haber: command not found Patch does not have a valid e-mail address. The problem lies in .git/rebase-apply/author-script : GIT_AUTHOR_NAME='Rene'́ Haber GIT_AUTHOR_EMAIL='rene@habr.de' GIT_AUTHOR_DATE='@1330931169 +0100' where the accent ´ is on top of the apostrophe and an apostrophe is missing from the end of the GIT_AUTHOR_NAME line. This leads to the "Haber: command not found". As the author name is taken from the rebased commits changing the user.name in the .gitconfig is useless. The only way I found around this is changing my name to "Rene Haber" and first rewriting my local history up to the point of the rebase with that name. Thanks for your help. René Haber ``` ## Jeff King, 2012-03-05 10:26 Subject: Re: Bug: pull --rebase with é in name Message-ID: <20120305102657.GB29061@sigill.intra.peff.net> URL: https://gitlist.dev/e/20120305102657.GB29061%40sigill.intra.peff.net In-Reply-To: ``` On Mon, Mar 05, 2012 at 10:59:16AM +0100, René Haber wrote: > I'm having trouble with the following scenario: > My name contains an é with accent. Having set > git config --global user.name "René Haber" > and several commits with that name in a project. That should work in general, but... > git pull --rebase > [...] > /sw/lib/git-core/git-am: line 675: Haber: command not found > > The problem lies in .git/rebase-apply/author-script : > > GIT_AUTHOR_NAME='Rene'́ Haber > GIT_AUTHOR_EMAIL='rene@habr.de' > GIT_AUTHOR_DATE='@1330931169 +0100' That's definitely not right. I can't seem to reproduce it here with a simple test (neither with "René" in the author name, nor with an author name containing single-quote). What version of git are you using (it looks like a recent one, as it has the magic @-date syntax). Have you set i18n.commitencoding, or are otherwise using an encoding besides utf8? Is it possible to share the commits that trigger this bug? -Peff ``` ## Thomas Rast, 2012-03-05 10:37 Subject: Re: Bug: pull --rebase with é in name Message-ID: <87399nqqog.fsf@thomas.inf.ethz.ch> URL: https://gitlist.dev/e/87399nqqog.fsf%40thomas.inf.ethz.ch In-Reply-To: <20120305102657.GB29061@sigill.intra.peff.net> ``` Jeff King writes: > On Mon, Mar 05, 2012 at 10:59:16AM +0100, René Haber wrote: > >> I'm having trouble with the following scenario: >> My name contains an é with accent. Having set >> git config --global user.name "René Haber" >> and several commits with that name in a project. > > That should work in general, but... > >> git pull --rebase >> [...] >> /sw/lib/git-core/git-am: line 675: Haber: command not found >> >> The problem lies in .git/rebase-apply/author-script : >> >> GIT_AUTHOR_NAME='Rene'́ Haber >> GIT_AUTHOR_EMAIL='rene@habr.de' >> GIT_AUTHOR_DATE='@1330931169 +0100' > > That's definitely not right. > > I can't seem to reproduce it here with a simple test (neither with > "René" in the author name, nor with an author name containing > single-quote). What version of git are you using (it looks like a recent > one, as it has the magic @-date syntax). Have you set > i18n.commitencoding, or are otherwise using an encoding besides utf8? Is > it possible to share the commits that trigger this bug? Also, can you post a hex dump of the config that defines user.name (try 'xxd ~/.gitconfig'), so we can see the encoding of René? I find it pretty odd that Git manages to split the ´ from the e, so I'm wondering if perhaps you are using UTF-8 in NFD or similar. -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## René Haber, 2012-03-05 11:42 Subject: Re: Bug: pull --rebase with é in name Message-ID: URL: https://gitlist.dev/e/F5A485EA-7EAD-4D8B-87C4-7185F713318C%40habr.de In-Reply-To: <87399nqqog.fsf@thomas.inf.ethz.ch> ``` I'm running git 1.7.9.2 from Fink Project on MacOS X 10.6. The gitconfig in hex is attached. I'm not using i18n.commitencoding or a charset different from utf8. Thanks. René Am 05.03.2012 um 11:37 schrieb Thomas Rast: > Jeff King writes: > >> On Mon, Mar 05, 2012 at 10:59:16AM +0100, René Haber wrote: >> >>> I'm having trouble with the following scenario: >>> My name contains an é with accent. Having set >>> git config --global user.name "René Haber" >>> and several commits with that name in a project. >> >> That should work in general, but... >> >>> git pull --rebase >>> [...] >>> /sw/lib/git-core/git-am: line 675: Haber: command not found >>> >>> The problem lies in .git/rebase-apply/author-script : >>> >>> GIT_AUTHOR_NAME='Rene'́ Haber >>> GIT_AUTHOR_EMAIL='rene@habr.de' >>> GIT_AUTHOR_DATE='@1330931169 +0100' >> >> That's definitely not right. >> >> I can't seem to reproduce it here with a simple test (neither with >> "René" in the author name, nor with an author name containing >> single-quote). What version of git are you using (it looks like a recent >> one, as it has the magic @-date syntax). Have you set >> i18n.commitencoding, or are otherwise using an encoding besides utf8? Is >> it possible to share the commits that trigger this bug? > > Also, can you post a hex dump of the config that defines user.name (try > 'xxd ~/.gitconfig'), so we can see the encoding of René? > > I find it pretty odd that Git manages to split the ´ from the e, so I'm > wondering if perhaps you are using UTF-8 in NFD or similar. > > -- > Thomas Rast > trast@{inf,student}.ethz.ch ``` ## Jeff King, 2012-03-05 11:58 Subject: Re: Bug: pull --rebase with é in name Message-ID: <20120305115815.GA4550@sigill.intra.peff.net> URL: https://gitlist.dev/e/20120305115815.GA4550%40sigill.intra.peff.net In-Reply-To: ``` On Mon, Mar 05, 2012 at 12:42:14PM +0100, René Haber wrote: > I'm running git 1.7.9.2 from Fink Project on MacOS X 10.6. > The gitconfig in hex is attached. Hmm, looks like pretty standard utf8: 0000020: 6d65 203d 2052 656e c3a9 2048 6162 6572 me = Ren.. Haber and the same thing I used in my tests. I tried repeating the test with v1.7.9.2 on OS X (although my test box is 10.7), and couldn't replicate it. Can you show us the commit that causes the problem, as printed by "git cat-file commit $commit | xxd"? I just want to double-check that there are no odd bytes there. Also, what happens if you do: sh -c ' . /sw/lib/git-core/git-sh-setup get_author_ident_from_commit $commit ' (my theory is that this is the underlying problem in the rebase, and should show the bug; by narrowing it down, it should make testing a lot simpler). -Peff ``` ## Jakub Narebski, 2012-03-05 12:36 Subject: Re: Bug: pull --rebase with é in name Message-ID: URL: https://gitlist.dev/e/m3aa3vteat.fsf%40localhost.localdomain In-Reply-To: <20120305115815.GA4550@sigill.intra.peff.net> ``` Jeff King writes: > On Mon, Mar 05, 2012 at 12:42:14PM +0100, René Haber wrote: > > > I'm running git 1.7.9.2 from Fink Project on MacOS X 10.6. > > The gitconfig in hex is attached. > > Hmm, looks like pretty standard utf8: > > 0000020: 6d65 203d 2052 656e c3a9 2048 6162 6572 me = Ren.. Haber > > and the same thing I used in my tests. I tried repeating the test with > v1.7.9.2 on OS X (although my test box is 10.7), and couldn't replicate > it. > > Can you show us the commit that causes the problem, as printed by "git > cat-file commit $commit | xxd"? I just want to double-check that there > are no odd bytes there. > > Also, what happens if you do: > > sh -c ' > . /sw/lib/git-core/git-sh-setup > get_author_ident_from_commit $commit > ' > > (my theory is that this is the underlying problem in the rebase, and > should show the bug; by narrowing it down, it should make testing a lot > simpler). Hmmm... one place where I have read about this strange "René" -> "Rene'" conversion is when terminal (console) cannot display unicode, and tries to show it using ASCII: http://stackoverflow.com/a/9430419/46058 But it should not matter if we are writing to file, isn't it? -- Jakub Narębski ``` ## René Haber, 2012-03-05 12:46 Subject: Re: Bug: pull --rebase with é in name Message-ID: <0E2B8DE3-1ABD-453F-BCAA-0D693ECA5987@habr.de> URL: https://gitlist.dev/e/0E2B8DE3-1ABD-453F-BCAA-0D693ECA5987%40habr.de In-Reply-To: <20120305115815.GA4550@sigill.intra.peff.net> ``` sh -c ' . /sw/lib/git-core/git-sh-setup get_author_ident_from_commit 16b94413cbce12531e8f946286851598449d3913 ' GIT_AUTHOR_NAME='Ren'é Haber GIT_AUTHOR_EMAIL='rene@habr.de' GIT_AUTHOR_DATE='@1329212923 +0100' Commit attached. The thing is, that this only happens when I do git pull --rebase. Doing a git rebase -i HEAD~5 or so works. Am 05.03.2012 um 12:58 schrieb Jeff King: > On Mon, Mar 05, 2012 at 12:42:14PM +0100, René Haber wrote: > >> I'm running git 1.7.9.2 from Fink Project on MacOS X 10.6. >> The gitconfig in hex is attached. > > Hmm, looks like pretty standard utf8: > > 0000020: 6d65 203d 2052 656e c3a9 2048 6162 6572 me = Ren.. Haber > > and the same thing I used in my tests. I tried repeating the test with > v1.7.9.2 on OS X (although my test box is 10.7), and couldn't replicate > it. > > Can you show us the commit that causes the problem, as printed by "git > cat-file commit $commit | xxd"? I just want to double-check that there > are no odd bytes there. > > Also, what happens if you do: > > sh -c ' > . /sw/lib/git-core/git-sh-setup > get_author_ident_from_commit $commit > ' > > (my theory is that this is the underlying problem in the rebase, and > should show the bug; by narrowing it down, it should make testing a lot > simpler). > > -Peff ``` ## Thomas Rast, 2012-03-05 13:04 Subject: Re: Bug: pull --rebase with é in name Message-ID: <87ipijkxlm.fsf@thomas.inf.ethz.ch> URL: https://gitlist.dev/e/87ipijkxlm.fsf%40thomas.inf.ethz.ch In-Reply-To: <0E2B8DE3-1ABD-453F-BCAA-0D693ECA5987@habr.de> ``` René Haber writes: > sh -c ' > . /sw/lib/git-core/git-sh-setup > get_author_ident_from_commit 16b94413cbce12531e8f946286851598449d3913 > ' > GIT_AUTHOR_NAME='Ren'é Haber > GIT_AUTHOR_EMAIL='rene@habr.de' > GIT_AUTHOR_DATE='@1329212923 +0100' I think this is the same issue that we recently discussed on #git-devel, where some broken versions of sed will fail to match "any character" with '.' even under LC_ALL=C. Will "shruggar" Palmer (cc) had this issue under OS X with a build of GNU sed that ignored LC_*. You can verify that this is the problem by looking at printf "\370\235\204\236\n" | LC_CTYPE=C sed 's/./x/g' | xxd It should say 0000000: 7878 7878 0a xxxx. That is, the garbage (if you try to read it as UTF-8) in the printf string was matched and replaced byte-by-byte with 'x'. However, Will was getting the unreplaced results 0000000: f89d 849e 0a ..... I'm not sure he has followed up on that problem; the only hope may be to get a better 'sed'. -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## René Haber, 2012-03-05 13:19 Subject: Re: Bug: pull --rebase with é in name Message-ID: <47F94015-B812-4034-9910-17912AC0ADA7@habr.de> URL: https://gitlist.dev/e/47F94015-B812-4034-9910-17912AC0ADA7%40habr.de In-Reply-To: <87ipijkxlm.fsf@thomas.inf.ethz.ch> ``` Am 05.03.2012 um 14:04 schrieb Thomas Rast: > René Haber writes: > >> sh -c ' >> . /sw/lib/git-core/git-sh-setup >> get_author_ident_from_commit 16b94413cbce12531e8f946286851598449d3913 >> ' >> GIT_AUTHOR_NAME='Ren'é Haber >> GIT_AUTHOR_EMAIL='rene@habr.de' >> GIT_AUTHOR_DATE='@1329212923 +0100' > > I think this is the same issue that we recently discussed on #git-devel, > where some broken versions of sed will fail to match "any character" > with '.' even under LC_ALL=C. Will "shruggar" Palmer (cc) had this > issue under OS X with a build of GNU sed that ignored LC_*. > > You can verify that this is the problem by looking at > > printf "\370\235\204\236\n" | LC_CTYPE=C sed 's/./x/g' | xxd > > It should say > > 0000000: 7878 7878 0a xxxx. > > That is, the garbage (if you try to read it as UTF-8) in the printf > string was matched and replaced byte-by-byte with 'x'. However, > Will was getting the unreplaced results > > 0000000: f89d 849e 0a ..... > > I'm not sure he has followed up on that problem; the only hope may be to > get a better 'sed'. I can conform this. I get ..... Using the sed from apple results in xxxx. Thanks. René > -- > Thomas Rast > trast@{inf,student}.ethz.ch ``` ## Jeff King, 2012-03-05 13:29 Subject: Re: Bug: pull --rebase with é in name Message-ID: <20120305132913.GA15004@sigill.intra.peff.net> URL: https://gitlist.dev/e/20120305132913.GA15004%40sigill.intra.peff.net In-Reply-To: <87ipijkxlm.fsf@thomas.inf.ethz.ch> ``` On Mon, Mar 05, 2012 at 02:04:37PM +0100, Thomas Rast wrote: > René Haber writes: > > > sh -c ' > > . /sw/lib/git-core/git-sh-setup > > get_author_ident_from_commit 16b94413cbce12531e8f946286851598449d3913 > > ' > > GIT_AUTHOR_NAME='Ren'é Haber > > GIT_AUTHOR_EMAIL='rene@habr.de' > > GIT_AUTHOR_DATE='@1329212923 +0100' > [...] > That is, the garbage (if you try to read it as UTF-8) in the printf > string was matched and replaced byte-by-byte with 'x'. However, > Will was getting the unreplaced results > > 0000000: f89d 849e 0a ..... > > I'm not sure he has followed up on that problem; the only hope may be to > get a better 'sed'. Long ago, 47c9739e replaced the shell quoting in git-am with "git rev-parse --sq-quote" (instead of sed). Maybe we can do the same for get_author_ident_from_commit (though it is a little trickier there, as we are also parsing values directly out of --pretty=raw). It would be nice if the --pretty format placeholders had a "shell-quote" modifier, and we could just do: git show --format='GIT_AUTHOR_NAME=%(an:shell)' or something similar. for-each-ref knows about shell-quoting, but we can't use it here, because we are looking at arbitrary commits, not just ones pointed to by refs. -Peff ``` ## Thomas Rast, 2012-03-05 13:40 Subject: Re: Bug: pull --rebase with é in name Message-ID: <87r4x7jhd9.fsf@thomas.inf.ethz.ch> URL: https://gitlist.dev/e/87r4x7jhd9.fsf%40thomas.inf.ethz.ch In-Reply-To: <20120305132913.GA15004@sigill.intra.peff.net> ``` Jeff King writes: > On Mon, Mar 05, 2012 at 02:04:37PM +0100, Thomas Rast wrote: > >> René Haber writes: >> >> > sh -c ' >> > . /sw/lib/git-core/git-sh-setup >> > get_author_ident_from_commit 16b94413cbce12531e8f946286851598449d3913 >> > ' >> > GIT_AUTHOR_NAME='Ren'é Haber >> > GIT_AUTHOR_EMAIL='rene@habr.de' >> > GIT_AUTHOR_DATE='@1329212923 +0100' >> [...] >> That is, the garbage (if you try to read it as UTF-8) in the printf >> string was matched and replaced byte-by-byte with 'x'. However, >> Will was getting the unreplaced results >> >> 0000000: f89d 849e 0a ..... >> >> I'm not sure he has followed up on that problem; the only hope may be to >> get a better 'sed'. [...] > It would be nice if the --pretty format placeholders had a "shell-quote" > modifier, and we could just do: > > git show --format='GIT_AUTHOR_NAME=%(an:shell)' > > or something similar. for-each-ref knows about shell-quoting, but we > can't use it here, because we are looking at arbitrary commits, not just > ones pointed to by refs. Perhaps by using %an etc., line numbers and --sq-quote: $ git rev-list --no-walk --date=raw --format="%an%n%ae%n%ad" --encoding=UTF-8 HEAD | while read -r s; do git rev-parse --sq-quote "$s"; done | sed -n -e '2s/^ /GIT_AUTHOR_NAME=/p' -e '3s/^ /GIT_AUTHOR_EMAIL=/p' -e '4s/^ /GIT_AUTHOR_DATE=/p' GIT_AUTHOR_NAME='Thom'\''as Ràst' GIT_AUTHOR_EMAIL='trast@inf.ethz.ch' GIT_AUTHOR_DATE='1330935546 +0100' This is for a commit where I deliberately mangled my author line to make an interesting example, as in $ git cat-file commit HEAD | grep ^author author Thom'as Ràst 1330935546 +0100 I tried doing the quoting inside sed instead of the while...rev-parse --sq-quote, but it made my head hurt. -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## Jeff King, 2012-03-05 13:50 Subject: Re: Bug: pull --rebase with é in name Message-ID: <20120305135010.GA17189@sigill.intra.peff.net> URL: https://gitlist.dev/e/20120305135010.GA17189%40sigill.intra.peff.net In-Reply-To: <87r4x7jhd9.fsf@thomas.inf.ethz.ch> ``` On Mon, Mar 05, 2012 at 02:40:34PM +0100, Thomas Rast wrote: > > It would be nice if the --pretty format placeholders had a "shell-quote" > > modifier, and we could just do: > > > > git show --format='GIT_AUTHOR_NAME=%(an:shell)' > > > > or something similar. for-each-ref knows about shell-quoting, but we > > can't use it here, because we are looking at arbitrary commits, not just > > ones pointed to by refs. > > Perhaps by using %an etc., line numbers and --sq-quote: > > $ git rev-list --no-walk --date=raw --format="%an%n%ae%n%ad" --encoding=UTF-8 HEAD | > while read -r s; do git rev-parse --sq-quote "$s"; done | > sed -n -e '2s/^ /GIT_AUTHOR_NAME=/p' -e '3s/^ /GIT_AUTHOR_EMAIL=/p' -e '4s/^ /GIT_AUTHOR_DATE=/p' > GIT_AUTHOR_NAME='Thom'\''as Ràst' > GIT_AUTHOR_EMAIL='trast@inf.ethz.ch' > GIT_AUTHOR_DATE='1330935546 +0100' Yeah, that works. It's a little harder to read than would be ideal, but should produce the right results (I was initially hesitant to use "read" because I was worried about newlines in the input. But of course, that's a non-issue since author ident by definition cannot have newlines in it). I think this is a good direction regardless of the sed issue. We end up parsing ident lines like this in a lot of different places, and I would not be surprised if they do not all behave exactly the same. Eliminating one such parser in favor of the standard one in pretty.c seems like a good thing. -Peff PS If you are going to turn that into a real patch, note that your date field accidentally drops the "@" specifier that unambiguously marks the number as an epoch timestamp. ``` ## Junio C Hamano, 2012-03-05 17:23 Subject: Re: Bug: pull --rebase with é in name Message-ID: <7v8vjf2c8o.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v8vjf2c8o.fsf%40alter.siamese.dyndns.org In-Reply-To: <20120305132913.GA15004@sigill.intra.peff.net> ``` Jeff King writes: > It would be nice if the --pretty format placeholders had a "shell-quote" > modifier, and we could just do: > > git show --format='GIT_AUTHOR_NAME=%(an:shell)' > > or something similar. for-each-ref knows about shell-quoting, but we > can't use it here, because we are looking at arbitrary commits, not just > ones pointed to by refs. You guys seem to have been having a lot of fun overnight. Perhaps I should live on European time? I think there were talks about cross pollinating and eventually unifying the placeholder languages of pretty and for-each-ref, and if we were to do so, I agree that --pretty definitely should learn to do --sq. But I do not think we want to teach everything :shell; following the style of %w(), something more generic that would apply to any payload would be preferred, perhaps giving an end result like this: git show -s --format=' GIT_AUTHOR_NAME=%(sq-begin)%an%(sq-end) GIT_AUTHOR_EMAIL=%(sq-begin)%ae%(sq-end) ' which would be immediately `eval`-able. Also I wonder if it is time for "git-am" to make more use of direct knowledge of the $rebasing and the original commit. Perhaps by teaching commit-tree to take the -c option from commit, we may not even have to worry about this. In any case, my reading of the conclusion you guys have already reached in this thread is that the issue is not even a bug in Git, but is a broken build/installation of sed by a third-party. I am inclined to suggest any change to get_author_ident_from_commit helper backburnered before we teach --sq to --pretty machinery. If the broken sed was the apple one that came with the platform, my conclusion might be different, but it seems to me that this is not something we would urgently have to worry about and patch our code up with an ugly band-aid workaround. ``` ## Jeff King, 2012-03-06 08:23 Subject: Re: Bug: pull --rebase with é in name Message-ID: <20120306082303.GC21199@sigill.intra.peff.net> URL: https://gitlist.dev/e/20120306082303.GC21199%40sigill.intra.peff.net In-Reply-To: <7v8vjf2c8o.fsf@alter.siamese.dyndns.org> ``` On Mon, Mar 05, 2012 at 09:23:19AM -0800, Junio C Hamano wrote: > I think there were talks about cross pollinating and eventually > unifying the placeholder languages of pretty and for-each-ref, and > if we were to do so, I agree that --pretty definitely should learn > to do --sq. But I do not think we want to teach everything :shell; > following the style of %w(), something more generic that would apply > to any payload would be preferred, perhaps giving an end result like > this: > > git show -s --format=' > GIT_AUTHOR_NAME=%(sq-begin)%an%(sq-end) > GIT_AUTHOR_EMAIL=%(sq-begin)%ae%(sq-end) > ' > > which would be immediately `eval`-able. Yeah, that could work. I didn't want to teach everything :shell individually. I was hoping eventually for a world where "%(foo:one:two=bar)" was internally parsed into "the foo item, with attribute one set, and attribute two set to bar". And then the "shell" attribute would have a particular meaning for everything, whereas in "%(authordate:format=short)", the "format" attribute would be specific to that item. I think that makes for a more readable syntax. However, your proposal does allow quoting multiple entities at a time, like: IDENT=%(sq-begin)%an <%ae>%(sq-end) which could be useful. Anyway, there is not much point in discussing hypothetical syntaxes. I think we agree that some form of this feature would be an ideal way forward in the long term, but specifics can wait until somebody shows up with patches. > In any case, my reading of the conclusion you guys have already > reached in this thread is that the issue is not even a bug in Git, > but is a broken build/installation of sed by a third-party. I am > inclined to suggest any change to get_author_ident_from_commit > helper backburnered before we teach --sq to --pretty machinery. I think that is true. It could be considered a bug in git if we were relying on an unportable sed construct. But it works everywhere else, and we already go to the effort to set LANG and LC_ALL, so I am inclined to say that it is not a portability issue in git, but a crappy sed implementation, and the right solution is to use a better one. We could switch the use of sed to perl (even just using 5.005-ish features, which are pretty portable), but until now, users of git-sh-setup don't need to rely on having perl at all. So I'm fine with leaving it for now and telling people to fix their sed. -Peff ``` ## Thomas Rast, 2012-03-06 08:36 Subject: Re: Bug: pull --rebase with é in name Message-ID: <87399mazxs.fsf@thomas.inf.ethz.ch> URL: https://gitlist.dev/e/87399mazxs.fsf%40thomas.inf.ethz.ch In-Reply-To: <7v8vjf2c8o.fsf@alter.siamese.dyndns.org> ``` Junio C Hamano writes: > Jeff King writes: > >> It would be nice if the --pretty format placeholders had a "shell-quote" >> modifier, and we could just do: >> >> git show --format='GIT_AUTHOR_NAME=%(an:shell)' >> >> or something similar. for-each-ref knows about shell-quoting, but we >> can't use it here, because we are looking at arbitrary commits, not just >> ones pointed to by refs. > > You guys seem to have been having a lot of fun overnight. Perhaps I > should live on European time? IIUC Peff just got up at an unreasonably early time to have fun with us Europeans? > I think there were talks about cross pollinating and eventually > unifying the placeholder languages of pretty and for-each-ref, and > if we were to do so, I agree that --pretty definitely should learn > to do --sq. But I do not think we want to teach everything :shell; > following the style of %w(), something more generic that would apply > to any payload would be preferred, perhaps giving an end result like > this: > > git show -s --format=' > GIT_AUTHOR_NAME=%(sq-begin)%an%(sq-end) > GIT_AUTHOR_EMAIL=%(sq-begin)%ae%(sq-end) > ' How about something along the lines of %Q(%an) instead? Though at least implementation-wise, it should be possible to make %'%an%' work, too, which would be rather cute. > In any case, my reading of the conclusion you guys have already > reached in this thread is that the issue is not even a bug in Git, > but is a broken build/installation of sed by a third-party. I am > inclined to suggest any change to get_author_ident_from_commit > helper backburnered before we teach --sq to --pretty machinery. Ok. This is the second "victim" of this broken install of sed, however. I wonder where René and Will got it from? Perhaps this is "the" common way of getting GNU sed on OS X, and thus more widespread than we might think. -- Thomas Rast trast@{inf,student}.ethz.ch ``` ## Jeff King, 2012-03-06 09:02 Subject: Re: Bug: pull --rebase with é in name Message-ID: <20120306090218.GG21199@sigill.intra.peff.net> URL: https://gitlist.dev/e/20120306090218.GG21199%40sigill.intra.peff.net In-Reply-To: <87399mazxs.fsf@thomas.inf.ethz.ch> ``` On Tue, Mar 06, 2012 at 09:36:31AM +0100, Thomas Rast wrote: > > You guys seem to have been having a lot of fun overnight. Perhaps I > > should live on European time? > > IIUC Peff just got up at an unreasonably early time to have fun with us > Europeans? Er...got up? Yeeeeeah, that's what happened. I would never stay up until 6am local time hacking on git. ;) > This is the second "victim" of this broken install of sed, however. I > wonder where René and Will got it from? Perhaps this is "the" common > way of getting GNU sed on OS X, and thus more widespread than we might > think. That's worth looking into, but the answer may still be "this common sed is broken, and we should tell the people who are packaging it to unbreak it". I'm worried that there really isn't a workaround (we are already trying LC_ALL and LANG; is there something else we can do short of not using sed at all?). -Peff ``` ## Junio C Hamano, 2012-03-06 18:31 Subject: Re: Bug: pull --rebase with é in name Message-ID: <7vmx7ttwcv.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vmx7ttwcv.fsf%40alter.siamese.dyndns.org In-Reply-To: <87399mazxs.fsf@thomas.inf.ethz.ch> ``` Thomas Rast writes: >> git show -s --format=' >> GIT_AUTHOR_NAME=%(sq-begin)%an%(sq-end) >> GIT_AUTHOR_EMAIL=%(sq-begin)%ae%(sq-end) >> ' > > How about something along the lines of %Q(%an) instead? Though at least > implementation-wise, it should be possible to make %'%an%' work, too, > which would be rather cute. It would be also less error prone from end user's point of view if your closing token is not ")" (as in %Q(%an)) but percent-something, e.g. %<%an%>, %`%an%', or %'%an%'. The way to quote a string that happens to be the same as closing token you want to put in the quoted string would be more obvious (e.g. ID=%Q(%ae (%an%29) is a bit hard to read for ID='gitster@pobox.com (J C H)'). ID=%'%ae (%an)%' As I do not expect these things to nest (do we want to be able to formulate a string that can be eval'ed twice???), using the same string for both opening and closing token is fine by me. ```