[WIP PATCH 0/2] Be more careful when prunning

[I turns out that my system was slightly misconfigured, so vger didn't want to accept my mail, this a re-send to the list only]

Hello,

I consider this WIP because I haven't addressed the issue when --tags is given. It's likely the most common issue (and what sparked this), but the second patch sets it up so it becomes easier.

The first patch is not that big a deal, but it's better if we're freeing the refspecs, we might as well free all of them.

The second patch teaches get_stale_heads to use the user-provided refspecs instead of the ones in the config. For example, running

    git fetch --prune origin refs/heads/master:refs/heads/master

doesn't remove the other branches anymore. For a more interesting (and believable) example, let's take

    git fetch --prune origin refs/heads/b/*:refs/heads/b/*

because you want to prune the refs inside the b/ namespace only. Currently git will delete all the refs that aren't under that namespace. With the second patch applied, git won't remove any refs outside the b/ namespace.

Now comes the interesting part: when --tags is given, there is no refspec set up, fetch just sets up a global variable. What I'm thinking (and going to implement after dinner, unless people cry out against it) is this: just before calling prune_refs, add a refspec to the user-provided list with the refspec refs/tags/*:refs/tags/* similar to what fetch_one does if you gave it "tag v1.5.6". This would cause us to ignore the configured refspec and keep the branches. The lack of '+' is most certainly on purpose. Is there anything fundamentally wrong with that idea?

Cheers,
   cmn

Carlos Martín Nieto (2):
  fetch: free all the additional refspecs
  fetch: honor the user-provided refspecs when pruning refs

 builtin/fetch.c  |    8 +++---
 builtin/remote.c |    2 +-
 remote.c         |   74 ++++++++++++++++++++++++++++++++++++++++++++++++-----
 remote.h         |    3 +-
 4 files changed, 74 insertions(+), 13 deletions(-)