Subject: Re: Applying .gitattributes text/eol changes

From: Michael J Gruber <[email-masked]>
Date: Fri, 14 Jan 2011 09:31:15 +0100

Junio C Hamano venit, vidit, dixit 14.01.2011 00:30:
> Marc Strapetz <[email-masked]> 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.

What I meant was to introduce a new option --refresh-stat or something.
We have solved the "stale stat info problem" (changed dev nums after
reboot) in a different way meanwhile, but I think there was a different
case (can't come up with the thread right now) where something like this
could have helped.

> 
>> 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.

Exactly, this is a more general issue. The typical answer to these
issues is that you change attributes and filters only occasionally, so
the cost of a rm .git/index && git reset --hard is irrelevant. But still
there should be a less scary way of (really) refreshing the index. Also
note that the cost of the command itself is only a part of the picture -
in the OP's case (which is a bit convoluted, of course) "cost" is really
command execution + the cost of the consequences (rebuilding triggered
by unnecessary touches). For the typical use cases, the existing options
and command paths do the perfectly sane and efficient thing.

Michael