All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	kasal@ucw.cz, sandals@crustytoothpaste.net
Subject: Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo
Date: Mon, 27 Apr 2015 10:47:29 -0700	[thread overview]
Message-ID: <xmqqa8xtxy32.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <xmqqzj5uxhls.fsf@gitster.dls.corp.google.com> (Junio C. Hamano's message of "Sun, 26 Apr 2015 22:31:11 -0700")

Junio C Hamano <gitster@pobox.com> writes:

> I suspect (I haven't looked very carefully for this round yet to be
> sure, though) that it may turn out that the commit you are proposing
> to revert was a misguided attempt to "fix" a non issue, or to break
> the behaviour to match a mistaken expectation.  If that is the case
> then definitely the reversion is a good idea, and you should argue
> along that line of justification.
>
> We'd just be fixing an old misguided and bad change in such a case.

The original says this:

    blame: correctly handle files regardless of autocrlf
    
    If a file contained CRLF line endings in a repository with
    core.autocrlf=input, then blame always marked lines as "Not
    Committed Yet", even if they were unmodified.  Don't attempt to
    convert the line endings when creating the fake commit so that blame
    works correctly regardless of the autocrlf setting.
    
    Reported-by: Ephrim Khong <dr.khong@gmail.com>
    Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

But if autocrlf=input, then the end-user expectation is to keep the
in-repository data with LF line endings.  If your tip-of-the-tree
commit incorrectly has CRLF line endings, and if you were going to
commit what is in the working tree on top, you would be correcting
that mistake by turning the in-repository data into a text file with
LF line endings, so "Not Committed Yet" _is_ the correct behaviour.

So I think that the reverting that change is the right thing to do.
It really was a change to break the behaviour to match a mistaken
expectation, I would have to say.

  parent reply	other threads:[~2015-04-27 17:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-26 12:02 [PATCH/RFC] blame: CRLF in the working tree and LF in the repo Torsten Bögershausen
2015-04-26 18:36 ` Eric Sunshine
2015-04-27  4:39 ` Stepan Kasal
2015-04-27  5:31 ` Junio C Hamano
2015-04-27  6:11   ` Stepan Kasal
2015-04-27 18:58     ` Johannes Sixt
2015-04-27 19:45       ` Torsten Bögershausen
2015-04-28 18:42         ` Johannes Sixt
2015-04-28 19:52           ` Junio C Hamano
2015-04-28 20:19             ` Johannes Sixt
2015-04-28 21:58               ` Stepan Kasal
2015-04-27 17:47   ` Junio C Hamano [this message]
2015-04-27 19:40     ` Torsten Bögershausen
2015-04-28  7:28       ` Junio C Hamano
2015-04-28  7:40         ` Torsten Bögershausen
2015-04-28  1:17     ` brian m. carlson

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=xmqqa8xtxy32.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=kasal@ucw.cz \
    --cc=sandals@crustytoothpaste.net \
    --cc=tboegi@web.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.