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

From: Jeff King <peff@peff.net>
Date: Mar 6, 2012, 08:23 UTC
Message-ID: <20120306082303.GC21199@sigill.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:

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