Junio C Hamano <gitster@xxxxxxxxx> writes: > Mike Hommey <mh@xxxxxxxxxxxx> writes: > >>> Does that mean the original code was doing a release that was >>> unnecessary? Or does it mean this patch changes what happens on >>> that codepath, namely (1) leaking resource, and/or (2) keeping a >>> tree of the original 'b' that does not have anything to do with the >>> tree of 's', preventing the later lazy-load code from reading the >>> tree of 's' and instead of building on top of a wrong tree content? >> >> I guess the question is whether branch_tree.tree can be in a state that >> doesn't match that of branch_tree.versions[1].sha1. If not, then if s >> and b have the same branch_tree.versions[1].sha1 for some reason, then >> keeping the old branch_tree.tree makes no practical difference from >> resetting it. Except it skips the busy-work. > > Perhaps my comment was misleading. I _think_ the state at the end > of this function (i.e. the latter hunk you added to the function > makes the above issue I raised go away). It just made me feel s/this function (/this function is good (/; > uneasy to leave branch_tree.tree and branch_tree.versions[] in an > inconsistent state inside this function, while it calls a few helper > functions (hence my comment on the fact that they do not seem to be > affected by this inconsistency). -- 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