Junio C Hamano <gitster@xxxxxxxxx> writes: > David Kastrup <dak@xxxxxxx> writes: > >> or has somebody a better idea or interface or rationale? I understand >> that there are use cases where one does not bother about empty >> directories, but for a _content_ tracker, not tracking directories >> because they are empty seems quite serious. > > No objections as long as a patch is cleanly made without > regression. It's just nobody agreed that it is "quite serious" > yet so far, and no fundamental reason against it. Thanks. It certainly is not serious for the Linux kernel source, but seems awkward for quite a few situations. Anyway, what is your take on the situation I described? That creating some directory hierarchy (happening to contain empty directories) with some external program, adding and committing it, then switching to a different branch (or maybe doing a git-reset --hard) leaves a skeleton of empty directories around? I find this almost worse than not being able to put them into the repository: you can't get rid of them anymore either! I'd be tempted to propose that git should remove empty subdirectories when cleaning up a removed tree in the working directory, even though that violates the principle to not delete anything it isn't tracking. But since you can't get it to track the stuff in the first place... But the real fix would be to track them. Does some trick work possibly at checkin time, like putting an empty file into every empty directory, adding to the index, then removing all empty files explicitly from the index and then checking in, or is this hopeless to work around with from the user side without affecting the repository itself? -- 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
