summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNicolas Pitre <nico@cam.org>2006-02-10 15:20:40 (GMT)
committerJunio C Hamano <junkio@cox.net>2006-02-10 17:21:02 (GMT)
commite7ad4a9c3c9d383d1df52410e18808174f7be667 (patch)
treef6f8243e253764ce03d096554f60ee24c3bf114d
parent4d44cb195aca5b744fd9f149af513637ff343a67 (diff)
downloadgit-e7ad4a9c3c9d383d1df52410e18808174f7be667.zip
git-e7ad4a9c3c9d383d1df52410e18808174f7be667.tar.gz
git-e7ad4a9c3c9d383d1df52410e18808174f7be667.tar.bz2
count-delta.c: comment fixes
There was a stale comment that explains why the old code could undercount when delta data copied things around inside detination buffer. We do not use that kind of delta, so the comment does not apply.
-rw-r--r--count-delta.c6
1 files changed, 1 insertions, 5 deletions
diff --git a/count-delta.c b/count-delta.c
index 978a60c..058a2aa 100644
--- a/count-delta.c
+++ b/count-delta.c
@@ -16,11 +16,7 @@
*
* Number of bytes that are _not_ copied from the source is deletion,
* and number of inserted literal bytes are addition, so sum of them
- * is the extent of damage. xdelta can express an edit that copies
- * data inside of the destination which originally came from the
- * source. We do not count that in the following routine, so we are
- * undercounting the source material that remains in the final output
- * that way.
+ * is the extent of damage.
*/
int count_delta(void *delta_buf, unsigned long delta_size,
unsigned long *src_copied, unsigned long *literal_added)