"Shubham Kanodia via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> From: Shubham Kanodia <shubham.kanodia10@xxxxxxxxx>
>
> Remote-tracking refs can accumulate in local repositories even as branches
> are deleted on remotes, impacting git performance negatively. Existing
> alternatives to keep refs pruned have a few issues —
>
> 1. Running `git fetch` with either `--prune` or `fetch.prune=true` set will
> prune stale refs, but requires a manual operation and also pulls in new
> refs from remote which can be an undesirable side-effect.
It is only true if you cloned without any tweaks. For example, if
you cloned with the single-branch option, you would not pull in new
refs, wouldn't you? Also "requires a manual operation" is not quite
a good rationale, as you could have placed such a "git fetch"
instead of "git remote prune", in the maintenance schedule.
For this to become an issue, the condition we saw in earlier
discussion, i.e.
while having the *default* refspec
"+refs/heads/*:refs/remotes/$name/*" configured in
remote.$name.fetch
is crucial. Since that is the default refspec "git clone" gives
you, your "git fetch --prune" would give you full set of refs while
pruning, and the end result is that you have up-to-date set of
remote-tracking branches (which you may not want).
> 2.`git remote prune` cleans up refs without adding to the existing list
> but requires periodic user intervention.
You have a SP after "1." but not after "2.".
> This adds a new maintenance task 'prune-remote-refs' that runs
> 'git remote prune' for each configured remote daily. This provides an
> automated way to clean up stale remote-tracking refs — especially when
> users may not do a full fetch.
"This adds" -> "Add".
I'd strike the latter sentence. Regardless of what users do or do
not do, the automated clean-up is performed.
> This task is disabled by default.
>
> Signed-off-by: Shubham Kanodia <shubham.kanodia10@xxxxxxxxx>
> ---
> +NOTE: This task is opt-in to prevent unexpected removal of remote refs
> +for users of git-maintenance. For most users, configuring `fetch.prune=true`
> +is a acceptable solution, as it will automatically clean up stale remote-tracking
"a acceptable" -> "an acceptable".
> +branches during normal fetch operations. However, this task can be useful in
> +specific scenarios:
> ++
> +--
> +* When using selective fetching (e.g., `git fetch origin +foo:refs/remotes/origin/foo`)
> + where `fetch.prune` would only affect refs that are explicitly fetched.
> +* When third-party tools might perform unexpected full fetches, and you want
> + periodic cleanup independently of fetch operations.
> +--
Very well written.
> @@ -913,6 +914,30 @@ static int maintenance_opt_schedule(const struct option *opt, const char *arg,
> return 0;
> }
>
> +static int prune_remote(struct remote *remote, void *cb_data UNUSED)
> +{
> + struct child_process child = CHILD_PROCESS_INIT;
> +
> + if (!remote->url.nr)
> + return 0;
> +
> + child.git_cmd = 1;
> + strvec_pushl(&child.args, "remote", "prune", remote->name, NULL);
> +
> + return !!run_command(&child);
> +}
> +
> +static int maintenance_task_prune_remote(struct maintenance_run_opts *opts,
> + struct gc_config *cfg UNUSED)
> +{
> + if (for_each_remote(prune_remote, opts)) {
> + error(_("failed to prune remotes"));
> + return 1;
> + }
> +
> + return 0;
> +}
Nice reuse of the program structure, which is very clean and easy to read.
Overall very well written. Will queue, with attached range-diff.
Thanks.
--- >8 ---
1: 0ae9668b5c ! 1: 8a40f8b319 maintenance: add prune-remote-refs task
@@ Commit message
Remote-tracking refs can accumulate in local repositories even as branches
are deleted on remotes, impacting git performance negatively. Existing
- alternatives to keep refs pruned have a few issues —
+ alternatives to keep refs pruned have a few issues:
- 1. Running `git fetch` with either `--prune` or `fetch.prune=true` set will
- prune stale refs, but requires a manual operation and also pulls in new
- refs from remote which can be an undesirable side-effect.
+ 1. Running `git fetch` with either `--prune` or `fetch.prune=true`
+ set, with the default refspec to copy all their branches into
+ our remote-tracking branches, will prune stale refs, but also
+ pulls in new branches from remote. That is undesirable if the
+ user wants to only work with a selected few remote branches.
- 2.`git remote prune` cleans up refs without adding to the existing list
- but requires periodic user intervention.
+ 2. `git remote prune` cleans up refs without adding to the
+ existing list but requires periodic user intervention.
- This adds a new maintenance task 'prune-remote-refs' that runs
- 'git remote prune' for each configured remote daily. This provides an
- automated way to clean up stale remote-tracking refs — especially when
- users may not do a full fetch.
-
- This task is disabled by default.
+ Add a new maintenance task 'prune-remote-refs' that runs 'git remote
+ prune' for each configured remote daily. Leave the task disabled by
+ default, as it may be unexpected to see their remote-tracking
+ branches to disappear while they are not watching for unsuspecting
+ users.
Signed-off-by: Shubham Kanodia <shubham.kanodia10@xxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
@@ Documentation/git-maintenance.txt: pack-refs::
++
+NOTE: This task is opt-in to prevent unexpected removal of remote refs
+for users of git-maintenance. For most users, configuring `fetch.prune=true`
-+is a acceptable solution, as it will automatically clean up stale remote-tracking
++is an acceptable solution, as it will automatically clean up stale remote-tracking
+branches during normal fetch operations. However, this task can be useful in
+specific scenarios:
++
