Re: [PATCH] Quote LF in urls git fetch saves in FETCH_HEAD

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 13 May 2009, Alex Riesen wrote:

> 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.

Looking back at the original message, it looks like the user included a 
newline in an argument to clone, and the fetch must have stripped it out 
(or ignored it in some other fashion), because data was retrieved from a 
repository that doesn't have a newline in its name. Most likely, the 
newline should just be prohibited in the URL in the config file in the 
first place, and we shouldn't be able to get to the point of writing a 
FETCH_HEAD with that value.

	-Daniel
*This .sig left intentionally blank*

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]