On Wed, Dec 18, 2024 at 9:05 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
...
> 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)
> 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
