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

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

Henrik Grubbström [off-list ref] writes:

quoted

quoted

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.

quoted

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.

[...]

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.

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