Johannes Sixt <j6t@xxxxxxxx> writes:
> Am 31.08.2013 01:55, schrieb Junio C Hamano:
>> People often find "git log --branches" etc. that includes _all_
>> branches is cumbersome to use when they want to grab most but except
>> some. The same applies to --tags, --all and --glob.
>>
>> Teach the revision machinery to remember patterns, and then upon the
>> next such a globbing option, exclude those that match the pattern.
>>
>> With this, I can view only my integration branches (e.g. maint,
>> master, etc.) without topic branches, which are named after two
>> letters from primary authors' names, slash and topic name.
>>
>> git rev-list --no-walk --exclude=??/* --branches |
>> git name-rev --refs refs/heads/* --stdin
>>
>> This one shows things reachable from local and remote branches that
>> have not been merged to the integration branches.
>>
>> git log --remotes --branches --not --exclude=??/* --branches
>>
>> It may be a bit rough around the edges, in that the pattern to give
>> the exclude option depends on what globbing option follows. In
>> these examples, the pattern "??/*" is used, not "refs/heads/??/*",
>> because the globbing option that follows the -"-exclude=<pattern>"
>> is "--branches". As each use of globbing option resets previously
>> set "--exclude", this may not be such a bad thing, though.
>
> I argued "--except should trump everything" earlier, but the case
> involving --not
>
> --branches --except maint --not master
>
> to mean the same as
>
> --branches --except maint master
>
> just does not make sense.
I'll have to mull the above two over to firmly grasp what you mean
by "'except' trumping 'not'" before deciding if you are agreeing or
disagreeing with the approach of taking it as a "taming wildcard"
issue...
> An alternative would be that --not would divide the command line
> arguments into ranges within which one --except would subtract
> subsequent refs from earlier globbing arguments in the same range.
> That's not simpler to explain than your current proposal.
>
> So I like the relative simplicity of this approach. Here is a bit of
> documentation.
Oh, thanks for helping. An example or two may also help, and using
your original "I have branches and wip/" situation would be good.
git log --exclude='wip/*' --branches::
Show history of local branches whose names do not
match pattern `wip/*`.
git log --remotes --not --exclude='wip/*' --branches::
Show history of other people's work that are not
merged to local branches whose names do not match
pattern `wip/*`.
or something like that, perhaps?
> --- 8< ---
> Subject: [PATCH] document --exclude option
>
> Signed-off-by: Johannes Sixt <j6t@xxxxxxxx>
> ---
> Documentation/rev-list-options.txt | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
> index 5bdfb42..650c252 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -174,6 +174,21 @@ parents) and `--max-parents=-1` (negative numbers denote no upper limit).
> is automatically prepended if missing. If pattern lacks '?', '{asterisk}',
> or '[', '/{asterisk}' at the end is implied.
>
> +--exclude=<glob-pattern>::
> +
> + Do not include refs matching '<glob-pattern>' that the next `--all`,
> + `--branches`, `--tags`, `--remotes`, or `--glob` would otherwise
> + consider. Repetitions of this option accumulate exclusion patterns
> + up to the next `--all`, `--branches`, `--tags`, `--remotes`, or
> + `--glob` option (other options or arguments do not clear
> + accumlated patterns).
> ++
> +The patterns given should not begin with `refs/heads`, `refs/tags`, or
> +`refs/remotes` when applied to `--branches`, `--tags`, or `--remotes`,
> +restrictively, and they must begin with `refs/` when applied to `--glob`
> +or `--all`. If a trailing '/{asterisk}' is intended, it must be given
> +explicitly.
> +
> --ignore-missing::
>
> Upon seeing an invalid object name in the input, pretend as if
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html