Re: Consider adding pruning of refs to git maintenance

From: Shubham Kanodia <shubham.kanodia10@gmail.com>
Date: Dec 22, 2024, 12:19 UTC
Message-ID: <CAG=Um+2cdMcys2x492_i47-qdvx5aJ7k6r=xSH5a3JZtMZBEZw@mail.gmail.com>
In-Reply-To: <xmqq34iluhqy.fsf@gitster.g>

On Wed, Dec 18, 2024 at 9:05 PM Junio C Hamano <gitster@pobox.com> wrote: ...

Show 7 quoted lines

> Ah, are they using "git fetch origin +foo:refs/remotes/origin/foo",
> i.e., only selectively fetch the thing that they use and nothing
> else (again, their wrappers may supply the refspec to do the
> limiting)?  Now it slowly starts to make sense to me (sorry, I am
> slow, especially without caffeine in the morning).
>
> Am I following / guessing your set-up more or less correctly so far?

Yes. The root cause of the issue here is that the behaviour that `git fetch` / `git pull` fetches all refs by default is undesirable in large git repositories. It's almost never what you want to do. We advice users to execute `git fetch <remote> <ref>` when they want to run fetch (/pull) explicitly.

Ideally, `git fetch` would only fetch the current branch when an explicit branch is not specified, and `git fetch --all` would pull in all. Now I believe git does provide a way to configure the default fetch refs via `remote.<name>.fetch`. So in theory I could just set —

```
[remote "origin"]
      fetch = +refs/heads/master:refs/remotes/origin/master
```

which would avoid someone pulling in all refs accidentally. However that has a side effect that now if you do want to fetch & start working on a remote ref that you weren't previously tracking, a command like

``` git fetch origin new-ref-branch-from-remote ```

no longer allows you to just start working on this new branch by doing a `git checkout new-ref-branch-from-remote`.

If you wanted to be able to do that, you'd probably need to do —

```
    git fetch origin new-ref-branch-from-remote
--refmap=+refs/heads/new-ref-branch-from-remote:refs/remotes/origin/new-ref-branch-from-remote
```

which is pretty awkward to type everytime.

Now to come back from this little digression, for now —
- We ask users to set both `fetch.prune` and `fetch.pruneTags` to true
(so that if a third party tool does do something, the damage is
limited and they don't have an ever-growing list of refs)
- Setup this job that cleans stale remote refs on a periodic basis,
which means that their ref counts heal over time (if they configure
all third party tools right)

Show 6 quoted lines

> Now, the documentation should explain when this "periodically running
> remote prune" is an acceptable workaround and/or a useful solution,
> relative to setting fetch.prune, as most parts of the existing
> documentation do assume that the users, intended audience of the
> document, are using the bog-standard "git clone" result, that copies
> all their branches to remote-tracking branches.

Agreed, will update docs to include that.

Thanks, Shubham K