Junio C Hamano venit, vidit, dixit 14.01.2011 00:30: > 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. 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 -- 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