Michael Haggerty wrote: > Scenario 1: Some providers junk up their users' repositories with > content that is not created by the repository's owner and that the owner > doesn't want to appear to vouch for (e.g., GitHub pull requests). These > references might sometimes be useful to fetch, singly or in bulk. > > Scenario 2: Some systems junk up their users' repositories with > additional references that are not interesting to most pullers (e.g., > Gerrit activity markers) though they don't add questionable content.
Actually Gerrit's refs/changes refs are pretty similar to Github's refs/pull. Both are requests for code review. [...] > But now every time I do a "gitk --all" or "git log --decorate", the > output is cluttered with all of his references (most of which are just > old versions of references from the upstream repository that we both > use). I would like to be able to hide his references most of the time > but turn them back on when I need them. > > Scenario 5: Our upstream repository has gazillions of release tags under > "refs/tags/releases/...", sometimes including customer-specific > releases. In my daily life these are just clutter. For both of these use cases, putting the refs somewhere other than refs/heads, refs/tags, and refs/remotes should be enough to avoid clutter. I agree that a --decorate-glob along the lines of "git rev-parse"'s --glob would be nice. [...] > * Some small improvements (e.g. allowing *multiple* views to be > defined) would provide much more benefit for about the same effort, > and would be a better base for building other features in the future > (e.g., local views). Would advertising GIT_CONFIG_PARAMETERS and giving examples for server admins to set it in inetd et al to provide different kinds of access to a same repository through different URLs work? > Thanks for listening. > Michael > > [1] Theoretically one could support multiple views of a single > repository by using something like "GIT_CONFIG=view_1_config git > upload-pack ..." or "git -c transfer.hiderefs=... git upload-pack ...", > but this would be awkward. Ah, I missed this comment before. What's awkward about that? I think it's a clean way to make many aspects of how a repository is presented (including hook actions) configurable. Thanks for your help clarifying this feature. Hopefully some of the discussion will filter into the documentation. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
