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