git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo

From
brian m. carlson <sandals@crustytoothpaste.net>
Date
Apr 28, 2015, 01:17 UTC
Message-ID
<20150428011702.GA5015@vauxhall.crustytoothpaste.net>
In-Reply-To
<xmqqa8xtxy32.fsf@gitster.dls.corp.google.com>
On Mon, Apr 27, 2015 at 10:47:29AM -0700, Junio C Hamano wrote:
Show 24 quoted lines
> 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.

I don't have a strong opinion on whether or not this should be reverted, since I don't use Windows and therefore don't use CRLF or the respective options anywhere, nor am I very familiar with how they are supposed to function. Junio has articulated a good rationale for why it's broken, and I'm willing to go along with that.

I will say that perhaps it's worthwhile to write some documentation to explain how the CRLF translation works, as it seems that there's a lot of misunderstanding about it. I am, for the aforementioned reasons, not a good choice to write it.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
Previous: Torsten Bögershausen
Message 16 of 16 in “blame: CRLF in the working tree and LF in the repo”
  1. blame: CRLF in the working tree and LF in the repoTorsten Bögershausen, Apr 26, 2015
  2. Eric SunshineApr 26, 2015
  3. Stepan KasalApr 27, 2015
  4. Junio C HamanoApr 27, 2015
  5. Stepan KasalApr 27, 2015
  6. Johannes SixtApr 27, 2015
  7. Torsten BögershausenApr 27, 2015
  8. Johannes SixtApr 28, 2015
  9. Junio C HamanoApr 28, 2015
  10. Johannes SixtApr 28, 2015
  11. Stepan KasalApr 28, 2015
  12. Junio C HamanoApr 27, 2015
  13. Torsten BögershausenApr 27, 2015
  14. Junio C HamanoApr 28, 2015
  15. Torsten BögershausenApr 28, 2015
  16. brian m. carlsonApr 28, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.