From: Wincent Colaiuta Date: Wed, 18 Jul 2007 06:34:27 GMT Subject: Re: Empty directories... Message-ID: In-Reply-To: <85d4yqz24s.fsf@lola.goethe.zz> 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