Re: [BUG] git-svn dcommit fails (connection closed unexpectedly)

[Linus Torvalds <torvalds@linux-foundation.org>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1682 bytes --]



On Sun, 13 May 2007, Eric Wong wrote:
> Karl Hasselström <kha@treskal.com> wrote:
> 
> > It might be a net win to let git-svn handle empty directories by
> > creating an empty .git-svn-empty-dir file in them, instead of
> > pretending they don't exist.
> 
> No.  This is *WAY* too ugly.

I wouldn't personally mind if somebody taught git to just track empty 
directories too.

There is no fundamental git database reason not to allow them: it's in 
fact quite easy to create an empty tree object. The problems with empty 
directories are in the *index*, and they shouldn't be insurmountable.

I never wanted empty directories for the kernel, but there is nothing 
really fundamentally wrong with them either. They do have some problems, 
which is why I don't particularly like tracking them, but if *not* 
tracking them causes more problems for people who import from SVN, I could 
easily see the balance moving towards "let people do it if they want".

In fact, I think the subproject support might have made it easier to track 
directories as empty directory entries. Pretty much every place that got 
impacted by subprojects would be where empty directory entries would be 
handled too.

In fact, one of the questions when tracking empty directories is whether 
you should track non-empty directories too. IOW, should we _always_ put 
the directory entry into the index (even when it's not empty), or should 
we do it only when somebody explicitly asks for it. I suspect the "always" 
case would is the right answer (ie a read-tree would always add a 
directory entry to the index before it starts adding the actual entries 
in the read-tree)

Anybody want to try it?

			Linus