Re: Bug: rebase when an author uses accents in name on MacOSx

[Jeff King <peff@peff.net>]

On Fri, Jun 01, 2012 at 09:19:26AM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> > [Please don't top-post.]
> > ...
> > But you have to keep in mind all of the people who will be led down the
> > wrong path by your breadcrumb when the failure is caused by a
> > _different_ problem. What is the probability that it is helpful versus
> > not helpful?  If you are going to give advice that sed might be broken,
> > you should at least test to see if it is broken and report it.
> 
> Eek, do that at runtime in the error code path?

Yes, which I think is utterly gross, but at least it is on the error
code path, so most people will never run it.

It's slightly less gross to do it at build-time (or even as part of
configure, I guess), but of course it is a run-time dependency, so there
is nothing to stop the broken sed from being installed after git (or
even a user with a different PATH than the builder triggering it).

One gross thing about doing it at run-time is that it only affects
_this_ code path, which happens to have an easy-to-diagnose outcome from
the bug. But how many other code paths are using sed on data which might
contain utf-8 characters? And are they failing silently or otherwise
simply corrupting the output?

One other thing to think about: this particular manifestation of the
bug is to cause our shell-quoting to fail. Are there are security
implications? That is, can I execute arbitrary code by having you run
get_author_ident_from_commit on a specially-crafted commit?

> The problem I see is that at that point where we have to suspect
> something fundamental as sed broken on the platform, we cannot even
> trust printf, test, or even the shell itself behaving sanely.

I don't think that's true. We have to deal with this kind of portability
nonsense all the time. We assume that the tools work until we get a
report that they don't, and then we fix it, work around it, or whatever.
Yes, the "your sed is broken" test would not work if "test" is also
totally broken. But we have not seen such a system in real life, or have
reason to suspect that it exists. Whereas we do know there is a
common[1] platform where the sed is broken in a specific way, but
nothing else is. Dealing with that helps solve a real problem for some
people.

-Peff

[1] I am just guessing about how common it is. I still haven't seen an
    indication of how common this version of sed is, or even which
    versions are affected.