threads / bug / 29834

Bug: pull --rebase with é in name

Subject: Bug: pull --rebase with é in name

## tl;dr

17 messages between Mar 5, 2012 and Mar 6, 2012.

replies: 16people: 5as markdown or json

René Haber· Mar 5, 2012, 09:59 UTC · lore
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· Mar 5, 2012, 10:26 UTC · re: René Haber · lore

Re: Bug: pull --rebase with é in name

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...
Show 9 quoted lines
> 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· Mar 5, 2012, 10:37 UTC · re: Jeff King · lore

Re: Bug: pull --rebase with é in name

Jeff King <peff@peff.net> writes:
Show 27 quoted lines
> 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· Mar 5, 2012, 11:42 UTC · re: Thomas Rast · lore

Re: Bug: pull --rebase with é in name

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:
Show 39 quoted lines
> Jeff King <peff@peff.net> 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· Mar 5, 2012, 11:58 UTC · re: René Haber · lore

Re: Bug: pull --rebase with é in name

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· Mar 5, 2012, 12:36 UTC · re: Jeff King · lore

Re: Bug: pull --rebase with é in name

Jeff King <peff@peff.net> writes:
Show 27 quoted lines
> 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· Mar 5, 2012, 12:46 UTC · re: Jeff King · lore

Re: Bug: pull --rebase with é in name

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:
Show 29 quoted lines
> 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· Mar 5, 2012, 13:04 UTC · re: René Haber · lore

Re: Bug: pull --rebase with é in name

René Haber <rene@habr.de> writes:
Show 7 quoted lines
> 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· Mar 5, 2012, 13:19 UTC · re: Thomas Rast · lore

Re: Bug: pull --rebase with é in name

Am 05.03.2012 um 14:04 schrieb Thomas Rast:
Show 31 quoted lines
> René Haber <rene@habr.de> 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· Mar 5, 2012, 13:29 UTC · re: Thomas Rast · lore

Re: Bug: pull --rebase with é in name

On Mon, Mar 05, 2012 at 02:04:37PM +0100, Thomas Rast wrote:
Show 18 quoted lines
> René Haber <rene@habr.de> 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· Mar 5, 2012, 13:40 UTC · re: Jeff King · lore

Re: Bug: pull --rebase with é in name

Jeff King <peff@peff.net> writes:
Show 20 quoted lines
> On Mon, Mar 05, 2012 at 02:04:37PM +0100, Thomas Rast wrote:
>
>> René Haber <rene@habr.de> 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'.
[...]
Show 8 quoted lines
> 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 <trast@inf.ethz.ch> 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· Mar 5, 2012, 13:50 UTC · re: Thomas Rast · lore

Re: Bug: pull --rebase with é in name

On Mon, Mar 05, 2012 at 02:40:34PM +0100, Thomas Rast wrote:
Show 17 quoted lines
> > 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· Mar 5, 2012, 17:23 UTC · re: Jeff King · lore

Re: Bug: pull --rebase with é in name

Jeff King <peff@peff.net> writes:
Show 8 quoted lines
> 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· Mar 6, 2012, 08:23 UTC · re: Junio C Hamano · lore

Re: Bug: pull --rebase with é in name

On Mon, Mar 05, 2012 at 09:23:19AM -0800, Junio C Hamano wrote:
Show 14 quoted lines
> 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.

Show 5 quoted lines
> 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· Mar 6, 2012, 08:36 UTC · re: Junio C Hamano · lore

Re: Bug: pull --rebase with é in name

Junio C Hamano <gitster@pobox.com> writes:
Show 13 quoted lines
> Jeff King <peff@peff.net> 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?

Show 12 quoted lines
> 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.

Show 5 quoted lines
> 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· Mar 6, 2012, 09:02 UTC · re: Thomas Rast · lore

Re: Bug: pull --rebase with é in name

On Tue, Mar 06, 2012 at 09:36:31AM +0100, Thomas Rast wrote:
Show 5 quoted lines
> > 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· Mar 6, 2012, 18:31 UTC · re: Thomas Rast · lore

Re: Bug: pull --rebase with é in name

Thomas Rast <trast@inf.ethz.ch> writes:
Show 8 quoted lines
>> 	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.

← back to recent threads