Re: [PATCH v3 4/6] revision: add new parameter to exclude hidden refs

[Jeff King <peff@peff.net>]

On Tue, Nov 08, 2022 at 09:16:47AM +0100, Patrick Steinhardt wrote:

> > > +--exclude-hidden=[transfer|receive|uploadpack]::
> > > +	Do not include refs that have been hidden via either one of
> > > +	`transfer.hideRefs`, `receive.hideRefs` or `uploadpack.hideRefs` that
> > > +	the next `--all`, `--branches`, `--tags`, `--remotes` or `--glob` would
> > > +	otherwise consider.  This option is cleared when seeing one of these
> > > +	pseudo-refs.
> > > +
> > 
> > Hmm. I thought that part of the motivation behind this round was to drop
> > the 'transfer' group, since it's implied by '--exclude-hidden=receive
> > --exclude-hidden-uploadpack', no?
> > 
> > Thanks,
> > Taylor
> 
> I didn't quite see the point in not providing the `transfer` group so
> that users can ask for only the set of refs that are hidden by both
> `uploadpack` and `receive`. But given that you're the second person
> asking for it to be dropped now and given that I don't really have a
> plausible usecase for this I'll drop it in the next version.

Sorry, I'm a little slow on the review. I just left a message in
response to v2 saying that I'm OK with it _if_ it's explained. But the
explanation above still seems misleading. Saying "either one of" implies
that they are mutually exclusive, but "receive" is really pulling from
"receive.hideRefs" and "transfer.hideRefs".

I think you'd need to lay out the rules. But if we just drop "transfer"
then that is simpler still (but the explanation probably still ought to
become "refs hidden by receive-pack" and not mention receive.hideRefs
explicitly).

-Peff