On Sun, Feb 01, 2009 at 10:48:29AM -0500, Jay Soffian wrote: > "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 -- 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
