Subject: Re: [PATCH v1 6/7] correct blame for files commited with CRLF

From: Junio C Hamano <[email-masked]>
Date: Tue, 29 Mar 2016 10:21:45 -0700

[email-masked] writes:

> From: Torsten Bögershausen <[email-masked]>
>
> git blame reports lines as not "Not Committed Yet" when they have
> CRLF in the index, CRLF in the worktree and e.g. core.autocrlf is true.
>
> Since commit c48053 "new safer autocrlf handling", files that have CRLF
> in the index are not normalized at commit when e.g. core.autocrl is set.
>
> Whenever a CLRF conversion is needed (or any filter us set), load the
> index temporally, before calling convert_to_git()

Sorry, but I do not understand what problem you are trying to
address here.

Under the same condition described in the first paragraph, what
would "git diff" and "git diff HEAD" say?  They should show that you
would be making a commit that corrects the line ending of the blob
recorded in the history.

The "Not Committed Yet" output from "git blame" is the same thing.
It is telling you that the commit you would be making by adding
that path from the working tree in its current state will become
the one that is responsible for the final state of the line.

So it is absolutely the right thing that these lines are shown as
"Not Commited Yet".  You will be making the line-ending correction
for the entire blob, and you should be made aware of it.

Now, it would be a very good idea for such a correction change to
have no other change, and it would be a very good idea to give users
a tool to see if there is any change other than the eol correction.
There is "git blame -w" to ignore whitespace changes, and I think
that would hide the CRLF/LF correction, but that hides all other kinds
of whitespace changes, so it is too broad for the purpose.

I do not think I'd be opposed to a new option to allow the command
to ignore _only_ eol changes (this applies not just to "blame" but
also to "diff", too).  That way:

 * The users can more easily make sure that the set of changes being
   prepared does not do anything other than correcting eol;

 * "git blame" can be told to relieve a commit of the responsibility
   for lines if the only change it did to them is to correct eol
   when digging the history (i.e. this will not just help "Not
   Committed Yet" changes in the working tree, but for digging
   through historical events).