Junio C Hamano <gitster@xxxxxxxxx> writes: > Another issue I thought about was what you would do in the step > 3 in the following: > > 1. David says "mkdir D; git add D"; you add S_IFDIR entry in > the index at D; > > 2. David says "date >D/F; git add D/F"; presumably you drop D > from the index (to keep the index more backward compatible) > and add S_IFREG entry at D/F. I don't think that one should drop D here. Operation 1 _is_ not backward compatible, so if you want to revert it, you should explicitly remove D. And we can't "keep" the index backward compatible if it isn't so after step 1. > 3. David says "git rm D/F". > > Have we stopped keeping track of the "empty directory" at this > point? The case I am worrying about is rather mkdir D mkdir D/E touch D/E/file git add D [*] git rm D/E/file >From a user perspective, E should be registered still. Compare this with mkdir D mkdir D/E touch D/E/file git add D/E/file [*] git rm D/E/file Where likely both D and E should now be considered unregistered. So the situation is different between the first or the second [*], and the difference might be impossible to express completely in the frame of a backwards-compatible index, even though we don't track an empty directory at the point [*] at all, and the only registered _file_ is D/E/file. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - 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
