On Wed, Mar 13, 2013 at 09:45:47AM -0700, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > > > David Aguilar <davvid@xxxxxxxxx> writes: > > > >>> The implementation of Junio's suggestion is relatively straightforward > >>> (this is untested, although t7800 passes, and can probably be improved > >>> by someone better versed in Perl). Does this work for your original > >>> scenario? > >> > >> This is a nice straightforward approach. > >> > >> As Junio mentioned, a good next step would be this patch in > >> combination with making the truly temporary files created by > >> dir-diff readonly. > > > > Even though I agree that the idea Matt McClure mentioned to run a > > three-way merge to take the modification back when the path checked > > out to the temporary tree as a temporary file (because it does not > > match the working tree version) gets edited by the user might be a > > better longer-term direction to go, marking the temporaries that the > > users should not modify clearly as such needs to be done in the > > shorter term. This thread wouldn't have had to happen if we had > > such a safety measure in the first place. > > One thing I forgot to add. I suspect the patch in the thread will > not work if the path needs smudge filter and end-of-line conversion, > as it seems to just hash-object what is in the working tree (which > should be _after_ these transformations) and compare with the object > name. The comparison should go the other way around. Try to check > out the object with these transformations applied, and compare the > resulting file with what is in the working tree. git-hash-object(1) implies that it will apply the clean filter and EOL conversion when it's given a path to a file in the working tree (as it is here). Is that not the case? John -- 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