git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Ondra Medek <xmedeko@gmail.com>, git@vger.kernel.org
Subject: Re: gitweb showing slash r at the end of line
Date: Sat, 28 Jan 2012 18:02:43 +0100	[thread overview]
Message-ID: <201201281802.44339.jnareb@gmail.com> (raw)
In-Reply-To: <7vvcnwybxj.fsf@alter.siamese.dyndns.org>

On Sat, 28 Jan 2012, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> Ondra Medek <xmedeko@gmail.com> writes:
>>
>>> we have gitweb running on Linux box. Some files have Windows line ending
>>> (CRLF) end we do not use core.autcrlf translation. gitweb show the last \r
>>> in the end of each line, which is annoying.
>>
>> Well, this "\r" allows to recognize when file with Windows line ending
>> (CRLF) made it into repository... which usually is discouraged.  But
>> if you allow this, I can understand that those "\r" at the end of
>> every line can be annoying.
> 
> I think the right thing to do is:
> 
>  * If the repository data is _supposed_ to have CRLF endings (e.g. check
>    with core.crlf or something), strip \r and do not show them.
> 
>  * Otherwise, i.e. if the repository data is supposed _not_ to have CRLF
>    endings, do show these '\r'.  Annoyance here is a *feature* to remind
>    the viewer that the contents needs _fixing_.
> 
>  * No other switches.

I agree that it would be a bast solution if gitweb could automatically
infer whether CRLF is allowed (whitelist) or disallowed (blacklist) in
files in given repository.  

But I am not sure if it is possible and what rules there should be for
a *BARE* repository; crlf and eol gitattributes and config variables
are about what should appear in working area - something gitweb is not
interested in at all.

If gitweb code was structured in different way, we could check if all
lines end in LF or all lines end in CRLF and add a note about that to
file or diff header, showing "\r" only in case of mixed line endings...
But that's a futile wish, for now at least.

-- 
Jakub Narebski
Poland

  reply	other threads:[~2012-01-28 17:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-27 14:19 gitweb showing slash r at the end of line Ondra Medek
2012-01-27 21:35 ` Jakub Narebski
2012-01-27 23:15   ` Junio C Hamano
2012-01-28 17:02     ` Jakub Narebski [this message]
2012-01-30  7:55       ` Ondra Medek
2012-01-30  9:23         ` Jakub Narebski
2012-01-30 16:09           ` Ondra Medek
2012-02-02 20:04             ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201201281802.44339.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=xmedeko@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).