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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 29, 2016, 17:21 UTC
Message-ID: <xmqqa8lhyzbq.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1459257938-17389-1-git-send-email-tboegi@web.de>

tboegi@web.de writes:

Show 10 quoted lines

> From: Torsten Bögershausen <tboegi@web.de>
>
> 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).