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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]