Re: [PATCH 03/15] run-job: implement fetch job

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 5, 2020, 20:28 UTC
Message-ID: <xmqqeet1y8wy.fsf@gitster.c.googlers.com>
In-Reply-To: <77b1da5d3063a2404cd750adfe3bb8be9b6c497d.1585946894.git.gitgitgadget@gmail.com>

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

> 1. One downside of the refs/hidden pattern is that 'git log' will
>    decorate commits with twice as many refs if they appear at a
>    remote ref (<remote>/<ref> _and_ refs/hidden/<remote>/<ref>). Is
>    there an easy way to exclude a refspace from decorations?

I do not think there is, but it makes sense to teach the decoration machinery to either use only certain refs hierarchies or use all hierarchies except for certain ones; if we want to make sure we won't break existing workflows, we should by defautlt use all the refs we currently use and nothing else, but over time we probably would want to migrate the default to cover only the local and remote-tracking branches and tags (and at that point, refs/hidden would be outside the decoration source).

By the way, I have a moderately strong opinion against the use of "refs/hidden" for the purpose of "prefetch in advance, without disrupting refs/remotes". There may be more than one reason why some refs want to be "hidden", and depending on the purose, the exact refs that one workflow (e.g. "decorate") wants to hide may be the ones that want to be exposed.

If we rename it to "refs/prefetch/", would it make the purpose of the hierarchy clearer without squatting on a vague (because it does not tell why it is hidden) name "hidden" that other people might want to use to hide their stuff for different reasons?

> Should
>    we make refs/hidden/* a "special" refspace that is excluded from
>    decorations?

See above.