[RFC 00/11] Make reference pruning more configurable

This patch series applies on top of

    mh/fetch-tags-in-addition-to-normal-refs

and has some minor conflicts with that branch (mostly related to documentation).

Let me state in advance that I personally think that the features implemented in this patch series are overkill. But since it was already implemented, I thought I would throw it out there and see if anybody likes it.

This patch series makes it possible for the user to specify explicitly which reference namespaces should be subjected to pruning when fetching from a remote.

* It allows a <pattern> to be passed to the --prune option for the
  following commands:

      git fetch --prune=<pattern> [...]
      git remote update --prune=<pattern> [...]
      git remote prune --prune=<pattern> [...]

          Only references that match the specified pattern(s) are
          considered for pruning.

      git remote show --prune=<pattern> [...]

          Only show prunable references that match the specified
          pattern(s).

  The --prune=<pattern> option can be specified multiple times.

* It introduces the following multivalued configuration values:

      fetch.pruneRef
      remote.<name>.pruneRef

          Configuration settings for setting the default
          "--prune=<pattern>" options, globally and per-remote.

Background: I started working on this feature as my first approach to
solving the problem that

    git fetch --tags --prune

can nuke tags unrelated to the remote being fetched from. Only later did I hit upon the better solution that is implemented in mh/fetch-tags-in-addition-to-normal-refs, namely to change the semantics of the --tags option to *not* subject tags to pruning.

But even though "--prune=<pattern>" is no longer needed to prevent tag nuking, it might be useful to somebody for other purposes, and therefore I am submitting it to the list as an RFC. Maybe there is a use case associated with non-branch, non-tag references, like perhaps Gerrit pull request-related references?

Personally, I am -0 on this series. I think it adds more complication (code, documentation, etc) than its usefulness justifies. I think the functionality in mh/fetch-tags-in-addition-to-normal-refs (which we want in any case!) will satisfy 99% of users and I can't think of use cases where additional configurability of reference pruning is needed.

So, if anybody can think of a compelling use case for this feature, please make your case!

Michael

Michael Haggerty (11):
  get_stale_heads(): allow limiting to refname patterns
  remote.c: add infrastructure for parsing --prune options
  fetch: use the new functions for handling --prune options
  remote: use the new functions for handling --prune options
  remote.c: add infrastructure to handle --prune=<pattern>
  fetch --prune: allow refname patterns to be specified
  remote update --prune: allow refname patterns to be specified
  string_list_append_list(): new function
  remote prune: allow --prune=<pattern> options
  remote show: allow --prune=<pattern> options
  remote: allow prune patterns to be configured

 Documentation/config.txt                    |  28 ++++--
 Documentation/fetch-options.txt             |  13 ++-
 Documentation/git-remote.txt                |  29 +++++--
 Documentation/technical/api-string-list.txt |  10 ++-
 builtin/fetch.c                             |  43 +++------
 builtin/remote.c                            |  85 ++++++++++++------
 remote.c                                    | 130 +++++++++++++++++++++++++++-
 remote.h                                    |  48 +++++++++-
 string-list.c                               |   9 ++
 string-list.h                               |   8 ++
 t/t5505-remote.sh                           |  88 +++++++++++++++++++
 t/t5510-fetch.sh                            |  25 ++++++
 12 files changed, 441 insertions(+), 75 deletions(-)