Dmitry Ivankov wrote: > new_tree_entry() doesn't zero or otherwise initialize the returned > entry, neither does release_tree_entry(). So it is quite possible > to get previously released data in a new entry. Thanks. Background for the confused: new_tree_entry / release_tree_entry manage a stack of tree_entry structs to use as temporaries. Initializing them is the responsibility of the caller, both after allocation with xmalloc() when existing temporaries are exhausted and after used entries are pushed with release_tree_entry(). > parse_ls doesn't set entry->versions[0] fields, but it does call > store_tree(entry) which looks for this base sha1 and tries to do > delta compression with that random object. > > Reset entry->versions[0] fields to make things more predictable > and to avoid surprises here. > > Signed-off-by: Dmitry Ivankov <divanorama@xxxxxxxxx> Good idea --- "root" is invalid at this point. Looks like a mistake introduced by my tweaks to v1.7.5-rc0~3^2~33 (fast-import: add 'ls' command, 2010-12-02). But isn't store_tree() only called on "leaf" which is completely zero-initialized? So I don't see why this change would have any effect. For what it's worth, even so, except for the commit message, Acked-by: Jonathan Nieder <jrnieder@xxxxxxxxx> -- 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