Am Mittwoch, 13. Mai 2009 schrieb Alex Riesen <raa.lkml@xxxxxxxxx>
> 2009/5/13 Junio C Hamano <gitster@xxxxxxxxx>:
> > Alex Riesen <raa.lkml@xxxxxxxxx> writes:
> >
> >> + for (i = 0; i < url_len; ++i)
> >> + if ('\n' == url[i])
> >> + fputs("\\n", fp);
> >> + else
> >> + fputc(url[i], fp);
> >> + fputc('\n', fp);
> >
> > This ad-hoc quoting feels _very_ wrong. Who is on the reading side and
> > how does it unquote?
>
> git fmt-merge-msg. It does not unquote. The url is purely informational here.
> OTOH, the \n shouldn't be in url text at all, so treat it as slightly
> less annoying
> warning.
>
> > If it is just informational use only, then it might make more sense to
> > drop this ugly "quoted \n" silently. I dunno.
>
> That'd mean to loose the information completely. Which is just as bad
> as putting the LF in the url in the first place.
> --
This stray linefeed is not information, but pure contamination. Thus it
would be much better to simply strip it off. And besides from the fact that
git apply rejects this patch (fatal: corrupt patch at line 6), I think it would
also not handle the equally wrong repository directory name on disk, which
then possibly leads to subsequent make failures (as it actually happend in
the case I described earlier here.) Why not just return to your original idea,
which proposed testing the repository name against a regular expression
describing a forbidden set of characters (which is "\n", currently) and then
terminate with a clear message?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html