On 4/5/2020 4:28 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> 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). I'll see what I can do about adding config to remove some refs from decorations. That is immediately useful for Scalar users, too. > 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? I like "refs/prefetch". That's more descriptive. >> Should >> we make refs/hidden/* a "special" refspace that is excluded from >> decorations? > > See above. Thanks, -Stolee
