[RFC 00/11] Make reference pruning more configurable

[Michael Haggerty <mhagger@alum.mit.edu>]

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(-)

-- 
1.8.4.3