From: Henrik Grubbström Date: Sun, 25 Apr 2010 11:25:11 GMT Subject: Re: [PATCH RFC 5/5] cache: Use ce_norm_sha1(). Message-ID: In-Reply-To: <7v7ho2gcpb.fsf@alter.siamese.dyndns.org> On Tue, 20 Apr 2010, Junio C Hamano wrote: > Henrik Grubbström 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. [...] > 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