Re: subdirectory-filter does not delete files before the directory came into existence?

From: Thomas Rast <trast@student.ethz.ch>
Date: Dec 19, 2010, 22:51 UTC
Message-ID: <201012192351.49279.trast@student.ethz.ch>
In-Reply-To: <1292751289.21229.26.camel@ct>

Jan Wielemaker wrote:

> On Sun, 2010-12-19 at 03:23 +0100, Thomas Rast wrote:
> > Jan Wielemaker wrote:
> > >   * get all tags, use comm and delete the tags not in the `contained'
> > >   set above.

[...]

> >   http://article.gmane.org/gmane.comp.version-control.git/91708

[...]

> Funny.  That was me having problems with filtering out directories
> as well :-)  I thought your patch was added using the --prune-empty
> flag.  I guess you can comment on that.  I can confirm that I've got
> nice and clean filtering using

No, those two are rather different. --prune-empty drops commits that became "no-ops" in the sense that their tree is the same as their (only) parent's. In the case of --subdirectory-filter, --prune-empty is most likely[*] redundant since the former already enables history simplification limited to that directory.

As you can see from "TOY PATCH", my patch wasn't really meant for application anyway. I'm now wondering what the ramifications would be. filter-branch only attempts to change refs that you told it to (listed positively on the command line), so maybe deleting anything that was not rewritten is a sensible option (not default, mind you).

[*] Read: I think it is redundant, I'm just too lazy to double-check.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch