From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: [PATCH v2 1/5] t5312: test object deletion code paths in a corrupted repository Date: Fri, 20 Mar 2015 14:43:02 -0400 Message-ID: <20150320184302.GA23849@peff.net> References: <20150320184215.GA26368@peff.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Junio C Hamano To: git@vger.kernel.org X-From: git-owner@vger.kernel.org Fri Mar 20 19:49:02 2015 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YZ1yb-00078T-Tp for gcvg-git-2@plane.gmane.org; Fri, 20 Mar 2015 19:48:58 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752035AbbCTSst (ORCPT ); Fri, 20 Mar 2015 14:48:49 -0400 Received: from cloud.peff.net ([50.56.180.127]:36028 "HELO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1751219AbbCTSnF (ORCPT ); Fri, 20 Mar 2015 14:43:05 -0400 Received: (qmail 29023 invoked by uid 102); 20 Mar 2015 18:43:04 -0000 Received: from Unknown (HELO peff.net) (10.0.1.1) by cloud.peff.net (qpsmtpd/0.84) with SMTP; Fri, 20 Mar 2015 13:43:04 -0500 Received: (qmail 26938 invoked by uid 107); 20 Mar 2015 18:43:16 -0000 Received: from sigill.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.7) by peff.net (qpsmtpd/0.84) with SMTP; Fri, 20 Mar 2015 14:43:16 -0400 Received: by sigill.intra.peff.net (sSMTP sendmail emulation); Fri, 20 Mar 2015 14:43:02 -0400 Content-Disposition: inline In-Reply-To: <20150320184215.GA26368@peff.net> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: When we are doing a destructive operation like "git prune", we want to be extra careful that the set of reachable tips we compute is valid. If there is any corruption or oddity, we are better off aborting the operation and letting the user figure things out rather than plowing ahead and possibly deleting some data that cannot be recovered. The tests here include: 1. Pruning objects mentioned only be refs with invalid names. This used to abort prior to d0f810f (refs.c: allow listing and deleting badly named refs, 2014-09-03), but since then we silently ignore the tip. Likewise, we test repacking that can drop objects (either "-ad", which drops anything unreachable, or "-Ad --unpack-unreachable=