On 02/06/2013 08:55 PM, Jonathan Nieder wrote: > Michael Haggerty wrote: > [...] >> 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.
Thanks, yes, for release tags in particular your suggestion might be workable. But I also like the idea of being able to turn subsets of references on and off easily, and have the choice persist until I change it. > [...] >> * 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. Awkwardness using GIT_CONFIG: the admin would have to maintain two separate config files with mostly overlapping content. Awkwardness using GIT_CONFIG_PARAMETERS or "-c transfer.hiderefs=...": the hiderefs configuration would have to be maintained in some Apache config or inetd or ... (or multiple places!) rather than in the repository's config file, where it belongs. Additional awkwardness using "-c transfer.hiderefs=...": AFAIK there is no way to turn *off* a configuration variable via a command-line option. It's all doable, but I find it awkward. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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
