Re: Consider adding pruning of refs to git maintenance

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 23, 2024, 04:21 UTC
Message-ID: <xmqqwmfr112w.fsf@gitster.g>
In-Reply-To: <CAG=Um+2cdMcys2x492_i47-qdvx5aJ7k6r=xSH5a3JZtMZBEZw@mail.gmail.com>

Shubham Kanodia <shubham.kanodia10@gmail.com> writes:

Show 8 quoted lines

> 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.

Or have this in your .git/config

    [remote "origin"]
	fetch = +refs/heads/new-ref-branch-from-remote:refs/remotes/origin/new-ref-branch-from-remote

and run

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

If you plan to do the same for more random branches, you could instead do

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

as long as you promise that you never run "git fetch" without saying which exact refs to fetch. I wonder if it helps to introduce a new configuration remote.*.fetchmap

    [remote "origin"]
	fetchmap = +refs/heads/*:refs/remotes/origin/*

that only talks about how the mapping goes without saying what gets fetched by default, so that the lack of remote.origin.fetch would cause

    $ git fetch origin
    $ git fetch

not to grab everything (like when you had the same specification as the value of remote.origin.fetch instead), but allows you to map whatever you grab from there when you did

    $ git fetch origin foo bar

If the glob pattern given by the fetchmap participated in how fetch.prune behaves (i.e. I see refs/remotes/origin/baz here, but while trying to fetch refs/heads/{foo,bar}, I notice that they no longer advertise refs/heads/baz---let me prune that stale one), that would make it much simpler.

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

Good.

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

OK.  And a scheduled task would make this part better.