Re: Applying .gitattributes text/eol changes

[Marc Strapetz <marc.strapetz@syntevo.com>]

>> What do you think about "git checkout --fix-eols" option as an
>> alternative? Its uses cases are more limited, though.
> 
> What does it do?  "git checkout --fix-eols $path" will overwrite $path
> with the data at $path in the index?  Perhaps you can use the "-f" option.
> 
> Adding an option to "checkout" might be better than update-index from the
> UI point of view, but the issue is not just "eols".  "eol" is a mere
> special case of smudge filter that controls how the contents from the
> repository are modified before getting written out to the working tree.

So there could be a "--thoroughly" option which will skip the stat check
(checkout_entry) and instead perform the procedure already outlined for
rebase:

> 	open object
>         read from the object
>         deflate and write to a temporary file
>         open the existing file
>         read from the file and compare it to the temporary we just wrote
>         if same, delete, otherwise rename the temporary file.

AFAIU, this change will effect mainly checkout struct, checkout_entry
and write_entry. write_entry already deals with temporary files, so that
shouldn't be too complex!?

--
Best regards,
Marc Strapetz
=============
syntevo GmbH
http://www.syntevo.com
http://blog.syntevo.com




On 14.01.2011 00:30, Junio C Hamano wrote:
> Marc Strapetz <marc.strapetz@syntevo.com> writes:
> 
>> So your suggestion is to fix "git update-index --really-refresh", so
> 
> The option is about telling git: "Earlier I promised I wouldn't touch
> these paths by setting their assume-unchanged bit, but I touched them.
> Please refresh the cached stat information in the index, ignoring the
> promise I didn't keep."
> 
> I do not think it is a good idea to conflate your "Everything is suspect
> because smudge filter has changed; please recompute all" request into the
> same option.  People who use assume-unchanged would probably want "Please
> rescan because I changed smudge filter" request to be carried out while
> still honoring the assume-unchanged bit they set earlier.
> 
>> Anyway, I'm still wondering if it will resolve the "git reset --hard"
>> problem of re-checking out every file, even if content is already
>> identical in the working tree. I think that part has to be fixed, too.
> 
> There is not much to fix there. If you removed the index, then there is no
> information to tell you that "content is already identical" unless you
> actually check things out and compare.  By the time you found it out, you
> already have done the checkout.
> 
> IOW, the current code does:
> 
> 	open object
>         read from the object
>         deflate and write to the destination file
> 
> while your "fix" needs to look like this:
> 
> 	open object
>         read from the object
>         deflate and write to a temporary file
>         open the existing file
>         read from the file and compare it to the temporary we just wrote
>         if same, delete, otherwise rename the temporary file.
> 
> just for the rare case where there is an untracked file that the user is
> willing to overwrite (we are discussing "rm .git/index && reset --hard"
> here) happens to have the same contents.  Not a good enough reason to add
> unwelcome complexity to the codepath.
> 
>> What do you think about "git checkout --fix-eols" option as an
>> alternative? Its uses cases are more limited, though.
> 
> What does it do?  "git checkout --fix-eols $path" will overwrite $path
> with the data at $path in the index?  Perhaps you can use the "-f" option.
> 
> Adding an option to "checkout" might be better than update-index from the
> UI point of view, but the issue is not just "eols".  "eol" is a mere
> special case of smudge filter that controls how the contents from the
> repository are modified before getting written out to the working tree.
> 
> 
> 
>