Re: Applying .gitattributes text/eol changes

quoted

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 [off-list ref] writes:

quoted

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.

quoted

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.

quoted

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.