Re: Possible --remove-empty bug

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

 




On Sun, 12 Mar 2006, Junio C Hamano wrote:
> 
> It removes the grandparents from the parent, and leaves the
> parent still interesting.  As a result, in your example:
> 
>     ... if you have
> 
>                 a
>                / \
>               b   c
>                \ /
>                 d
> 
>     where the pathname disappeared in "b"...
> 
> we would get this world view:
> 
>                 a
>                / \
>               b   c
>                  /
>                 d

Yeah, that's correct. That way you still see all the history that is 
relevant to the tree that became empty.

However, to be honest, the only reason to ever use --remove-empty is for 
rename detection, and Frederik's approach of doing that through the 
library interface directly is actually a much superior option. So we might 
as well drop the compilcation of --remove-empty entirely, unless somebody 
has already started using it.

The _real_ optimization would be to make the pathname based pruning be 
done incrementally instead of having to build up the whole tree. That 
would be much more important than the --remove-empty stuff from a 
usability standpoint. I'm absolutely sure it's possible, and I simplified 
the code earlier so that it should be simpler to do, but every time I 
actually look at the code I get confused again.

		Linus
-
: 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]