Jeff King wrote: > For most errors, we jump to a goto label that unlocks the > ref and returns NULL. However, in none of these error paths > would we ever have actually locked the ref. By the time we > actually take the lock, we follow a different path that does > not ever hit this goto (we rely on verify_lock to unlock if > it finds an error). [...] > refs.c | 12 ++++-------- > 1 file changed, 4 insertions(+), 8 deletions(-)
Wouldn't this leak lock (in all cases) and lock->ref_name and lock->orig_ref_name (on safe_create_leading_directories failure)? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
