Re: Empty directories...

[Wincent Colaiuta <win@wincent.com>]

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