>> 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@xxxxxxxxxxx> 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. > > > > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html