Re: [PATCH RFC 5/5] cache: Use ce_norm_sha1().

From: Henrik Grubbström <grubba@roxen.com>
Date: Apr 25, 2010, 11:25 UTC
Message-ID: <Pine.GSO.4.63.1004251252250.4423@shipon.roxen.com>
In-Reply-To: <7v7ho2gcpb.fsf@alter.siamese.dyndns.org>

On Tue, 20 Apr 2010, Junio C Hamano wrote:

Show 20 quoted lines

> Henrik Grubbström <grubba@roxen.com> writes:
>
>>> 3. "git update-index --refresh" does not improve the situation, as it
>>>    (thinks) it knows the blob and the working tree file are different.
>>
>> False. "git update-index --refresh" uses
>> read-cache.c:ce_compare_data() to compare the content of the blob with
>> the normalized content of the working tree,...
>
> I don't think you tried it yourself.  Here is what should happen with the
> current code.
>
> 	# step 0 & 1. a project with LF ending
> 	$ git init two && cd two
>        $ echo a quick brown fox >kuzu
>        $ git add kuzu && git commit -m kuzu
>
>        # step 2. you want CRLF in your work area
>        $ echo -e "a quick brown fox\015" >kuzu
>        $ git config core.autocrlf true

Ok, right. I thought step 2 was

 	$ git config core.autocrlf true
 	$ rm kuzu
 	$ git checkout -- kuzu

In which case the index will be clean.

> And it is a common thing people wish to do.  Admittedly, this is an one-off
> event, so it is not _that_ urgent to fix.  You can for example do:

I've fixed this case in my current version of the patches.

>> Let's take the reverse case instead:

[...]

Seems to depend on whether is_racy_timestamp is true or not. As you've noted, adding a touch forces the issue.

[...]

Show 6 quoted lines

> If you are trying to somehow make this last "git diff" silent, then I
> think you are solving a _wrong_ problem.  By setting retroactively the
> CRLF setting, you are saying that you do not want to have CRLF in the
> blobs recorded in the repository, and it is a _good thing_ that there are
> differences (tons of them) between what is recorded currently and what you
> are going to commit to fix the earlier mistake.

Ok, I've removed the diff-related changes from the current set of patches.

Show 8 quoted lines

> As I already said, I agree that it would be beneficial to store what
> normalization settings were used and comparing that with what settings are
> in effect to detect the possible phamtom difference caused by the change
> of the settings.  But once we know that the result of a re-normalization
> is different from what is recorded in the index (or tree), then the
> difference should be shown.  The actual difference would change every time
> the work tree file is edited, so I don't see the benefit of contaminate
> the object database with intermediate "blobs" that is not "added".

Ok. With the diff patches gone, there's no need to store the normalized blob data.

-- Henrik Grubbström grubba@grubba.org Roxen Internet Software AB grubba@roxen.com