Re: [PATCH 4/5] revision.c: refactor ref selection handler after --exclude

From: Jeff King <peff@peff.net>
Date: Jan 25, 2017, 20:57 UTC
Message-ID: <20170125205718.ksqstdnazmgbkehy@sigill.intra.peff.net>
In-Reply-To: <20170125125054.7422-5-pclouds@gmail.com>

On Wed, Jan 25, 2017 at 07:50:53PM +0700, Nguyễn Thái Ngọc Duy wrote:

Show 11 quoted lines

> Behavior change: "--exclude --blah --remotes" will not exclude remote
> branches any more. Only "--exclude --remotes" does.
> 
> This is because --exclude is going to have a new friend --decorate-reflog
> who haves the same way. When you allow a distant --remotes to complement
> a previous option, things get complicated. In
> 
>     --exclude .. --decorate-reflog ... --remotes
> 
> Does it mean decorate remote reflogs, or does it mean exclude remotes
> from the selected revisions?

I don't think it means either. It means to include remotes in the selected revisions, but excluding the entries mentioned by --exclude.

IOW:

  --exclude=foo --remotes
	include all remotes except refs/remotes/foo

  --exclude=foo --unrelated --remotes
        same

  --exclude=foo --decorate-reflog --remotes
        decorate reflogs of all remotes except "foo". Do _not_ use them
	as traversal tips.

  --decorate-reflog --exclude=foo --remotes
        same

IOW, the ref-selector options build up until a group option is given, which acts on the built-up options (over that group) and then resets the built-up options. Doing "--unrelated" as above is orthogonal (though I think in practice nobody would do that, because it's hard to read).

> Granted, there may be valid use cases for such a combination (e.g.
> "decorate all reflogs except remote ones") but I feel option order is
> not a good fit to express them.

That would be spelled:

  --exclude=refs/remotes --decorate-reflogs --all

(or you could swap the first two options).

Again, I'm not sure if I'm missing something subtle, or if you are confused about how --exclude works. :)

-Peff