Shubham Kanodia <shubham.kanodia10@xxxxxxxxx> writes:
> 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.
