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

[Jeff King <peff@peff.net>]

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