"Shawn O. Pearce" <spearce@spearce.org> wrote:
quoted text
> Junio C Hamano <gitster@pobox.com> wrote:
> > Another issue I thought about was what you would do in the step
> > 3 in the following:
> > 
> >  1. David says "mkdir D; git add D"; you add S_IFDIR entry in
> >     the index at D;
> > 
> >  2. David says "date >D/F; git add D/F"; presumably you drop D
> >     from the index (to keep the index more backward compatible)
> >     and add S_IFREG entry at D/F.
> > 
> >  3. David says "git rm D/F".
> > 
> > Have we stopped keeping track of the "empty directory" at this
> > point?
> 
> Sadly yes.  But I don't think that's what the folks who want to
> track empty directories want to have happen here.
> 
> Which is why I'm thinking we just need to track the directory, as a
> node in the index, even if there are files in it, and even if we got
> that directory and its contained files there by just unpacking trees.

I take this back.  I really don't want that behavior.

If I do:

  mkdir -p foo/bar
  echo hello >foo/bar/world
  git add foo
  git -f rm foo/bar/world

I never asked for foo/bar or foo to stay.  In fact I want them
to disappear from Git entirely, as foo/bar is now empty and has
no content.


But we also cannot do a special --mkdir option for update-index
either, because how do we know that the user designated subtree is
a directory we must always keep in the index?

So I think the only way this works is to have a new mode that we use
in tree (04755 ?) that tells us not only is this thing a subtree,
but also that the user wants it to stay here, even if it is empty.
Those trees are always in the index as a real tree entry, even if
there are files contained in it.

And as far as getting that directory entry created/removed from
the index, well, I think a special flag to update-index would be
in order, much like --chmod=[+-]x.

Just my $0.0002 USD, which really ain't worth much at all.

-- 
Shawn.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html