El 18/7/2007, a las 7:56, David Kastrup escribió:
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.
Although I haven't yet been "bitten" by this issue I understand where you're coming from. This could confuse users and appear inconsistent to them (seeing as empty *files* can be tracked). I think it's probably worth tackling for that reason alone, but it will have the additional benefit of enabling other workflows like the one you describe ("installation trees for some application").
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?
I wouldn't recommend any "tricks" here. I think the real solution is to allow the tracking of empty trees; everything else seems like a kludge. And then, as you've noted already that will allow Git to handle the "skeleton of empty directories" left behind problem that you describe.
Cheers, Wincent - 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
