Re: [PATCH] filter-branch: Fix renaming a directory in the tree-filter

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

 



Hi,

On Mon, 31 Mar 2008, Junio C Hamano wrote:

> Johannes Sixt <johannes.sixt@xxxxxxxxxx> writes:
> 
> > 2. Then filter-branch checks out the files for the next commit. This 
> >    leaves the new directory behind because there is no real "branch 
> >    switching" involved that would notice that the directory can be 
> >    removed.
> 
> Thanks.
> 
> It obviously is a correct fix to use "clean -d" here, but I strongly 
> suspect this awkwardness comes from the fact that there is no clear 
> invariant in this loop.
> 
> For example, if you make it the invariant that $T contains the tree that 
> matches the contents of the "$tempdir/t" work tree left in the previous 
> round of filter-tree (and obviously you would want to do this only 
> filter_tree is in effect), the "checkout-index + clean" would become a 
> proper "branch switching".
>
> This is obviously untested, and you would need to prime $T with an empty 
> tree before entering the loop (but you could cheat by initializing T 
> with an empty string), but it might make the code a bit more readable 
> than the current mess.  I dunno.

Yes, I'd prefer this.

Originally, I wanted to clean up filter-branch a little, but then somebody 
worked on a builtin version of it, which unfortunately came in after the 
code freeze, and I always waited for that thing to be picked up and 
enhanced.  (AFAIR there were quite a few issues which made rewrite-commits 
much less useful than it should be.)

Ciao,
Dscho
--
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]

  Powered by Linux