Re: [PATCH] builtin-remote: make rm operation safer in mirrored repository

From: Jeff King <peff@peff.net>
Date: Feb 2, 2009, 13:29 UTC
Message-ID: <20090202132909.GD8487@sigio.peff.net>
In-Reply-To: <1233503309-40144-1-git-send-email-jaysoffian@gmail.com>

On Sun, Feb 01, 2009 at 10:48:29AM -0500, Jay Soffian wrote:

Show 10 quoted lines

> "git remote rm <repo>" is happy to remove non-remote branches (and their
> reflogs). This may be okay if the repository truely is a mirror, but if the
> user had done "git remote add --mirror <repo>" by accident and was just
> undoing their mistake, then they are left in a situation that is difficult to
> recover from.
> 
> After this commit, "git remote rm" skips over non-remote branches and instead
> advises the user on how to remove such branches using "git branch -d", which
> itself has nice safety checks wrt to branch removal lacking from "git remote
> rm".

I think this is sensible. The point of "git remote rm" removing tracking branches is just to clean up cruft in a repository that has otherwise interesting stuff. Blowing away a mirror implies getting rid of all refs. At which point I have to wonder why you would want to do that versus just removing the repo entirely. I.e., the common use case for "git remote rm" on a mirror would seem to be "oops, I did this wrong" and not "I really want to get rid of all my refs".

So I think a safety valve is reasonable. I wonder if would be simpler still to just not delete _any_ refs for a mirrored remote. On the other hand, your safety valve also protects against unusual refspecs that might touch refs not in refs/remotes (e.g., if I didn't use remote.foo.mirror, but I had a manually-written refspec that touched some subset of refs/heads/). In that case, your safety valve makes more sense.

>  builtin-remote.c |    7 +++++++
>  1 files changed, 7 insertions(+), 0 deletions(-)

Tests?

-Peff