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

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 26, 2017, 09:28 UTC
Message-ID: <CACsJy8ATM_kc5SPY0dqprUefRy3vtpKW-4QEyJFK54jw0QgeJA@mail.gmail.com>
In-Reply-To: <20170125205718.ksqstdnazmgbkehy@sigill.intra.peff.net>

On Thu, Jan 26, 2017 at 3:57 AM, Jeff King <peff@peff.net> wrote:

Show 22 quoted lines

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

This is because it makes sense to combine --exclude and --decorate-reflog. But what about a new --something that conflicts with either --exclude or --decorate-reflog? Should we simply catch such combinations and error out (which may be a bit more complicated than this patch, or maybe not)?

-- 
Duy