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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
