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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 14, 2007, 17:26 UTC
Message-ID: <alpine.LFD.0.98.0705141016370.6739@woody.linux-foundation.org>
In-Reply-To: <20070513210128.GA13428@muzzle>

On Sun, 13 May 2007, Eric Wong wrote:

Show 7 quoted lines

> 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