From: Petr Baudis Date: Sun, 05 Jun 2005 20:40:47 GMT Subject: Re: [PATCH] diff.c: locate_size_cache() fix. Message-ID: <20050605204047.GQ17462@pasky.ji.cz> In-Reply-To: <7vwtpairlm.fsf@assigned-by-dhcp.cox.net> > This fixes two bugs. > > - declaration of auto variable "cmp" was preceeded by a > statement, causing compilation error on real C compilers; > noticed and patch given by Yoichi Yuasa. > > - the function's calling convention was overloading its size > parameter to mean "largest possible value means do not add > entry", which was a bad taste. Brought up during a > discussion with Peter Baudis. > > Signed-off-by: Junio C Hamano > This fixes a bug that was preventing non-default parameter to -B > option to be passed correctly; you could not give more than 50% > break score. > > Signed-off-by: Junio C Hamano > This fixes three bugs in the -B heuristics. > > - Although it was advertised that the initial break criteria > used was the same as what diffcore-rename uses, it was using > something different. Instead of using smaller of src and dst > size to compare with "edit" size, (insertion and deletion), > it was using larger of src and dst, unlike the rename/copy > detection logic. This caused the parameter to -B to mean > something different from the one to -M and -C. To compensate > for this change, the default break score is also changed to > match that of the default for rename/copy. > > - The code would have crashed with division by zero when trying > to break an originally empty file. > > - Contrary to what the comment said, the algorithm was breaking > small files, only to later merge them together. > > Signed-off-by: Junio C Hamano Hello, what's up with those three fixes? Were they pointed out to be wrong and thrown away in another thread, are they on hold or just dropped? Should I just apply them to git-pb? Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor