[PATCH] t6044: replace seq by test_seq

seq is not available everywhere. Signed-off-by: Johannes Sixt --- t/t6044-merge-unrelated-index-changes.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t6044-merge-unrelated-index-changes.sh b/t/t6044-merge-unrelated-index-changes.sh index

Re: [PATCH] fast-import: do not truncate exported marks file

Felipe Contreras writes: > On Tue, May 17, 2016 at 10:59 PM, Junio C Hamano wrote: >> On Tue, May 17, 2016 at 8:31 PM, Felipe Contreras >> wrote: >>> On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano

Re: [PATCH v4 2/2] convert: ce_compare_data() checks for a sha1 of a path

On 05/17/2016 08:58 PM, Junio C Hamano wrote: tbo...@web.de writes: #define HASH_WRITE_OBJECT 1 #define HASH_FORMAT_CHECK 2 +#define HASH_CE_HAS_SHA1 4 How does one pronounce the words in this constant? Does it make a listener understand what this constant means? How about

Re: [PATCH] fast-import: do not truncate exported marks file

On Tue, May 17, 2016 at 10:59 PM, Junio C Hamano wrote: > On Tue, May 17, 2016 at 8:31 PM, Felipe Contreras > wrote: >> On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano wrote: >>> - Even if we did not read from any existing

Re: [PATCH] fast-import: do not truncate exported marks file

On Tue, May 17, 2016 at 8:31 PM, Felipe Contreras wrote: > On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano wrote: >> Felipe Contreras writes: >> >> - Even if we are reading from somewhere, export_marks_file can >>

Re: [PATCH v2 3/5] t1500: avoid changing working directory outside of tests

On Tue, May 17, 2016 at 7:06 PM, SZEDER Gábor wrote: > Quoting Junio C Hamano : >> Jeff King writes: >>> On Tue, May 17, 2016 at 04:48:33PM -0400, Eric Sunshine wrote: On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano

Re: [PATCH] fast-import: do not truncate exported marks file

On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano wrote: > Felipe Contreras writes: > >> Certain lines of the marks file might be corrupted (or the objects >> missing due to a garbage collection), but that's no reason to truncate >> the file and

Ignore updates to files which are ignored, even if they're indexed.

TL;DR: Git should ignore files if they are in `.gitignore`, regardless of whether or not the file has changed (or been removed). Use Case An initial set of "local" config files are committed to a repo. Each developer will pull down this set of files, but changes will be auto-ignored unless the

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

On Tue, May 17, 2016 at 08:40:08PM -0400, Jeff King wrote: > So we need some way to tell strftime "...and by the way, this is the > timezone for the value we are currently feeding you." There isn't a slot > in "struct tm" for that, but I think maybe you can hack around it by > setting the global

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

On Tue, May 17, 2016 at 07:25:31PM +0200, Michael Heerdegen wrote: > Michael Heerdegen writes: > > > the command > > > >git log --pretty=format:%ad --date=format:%s > > > > displays wrong unixtime values; apparently how much the printed value > > differs from the

Re: [PATCH v2 3/5] t1500: avoid changing working directory outside of tests

Quoting Junio C Hamano : Jeff King writes: On Tue, May 17, 2016 at 04:48:33PM -0400, Eric Sunshine wrote: On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano wrote: Eric Sunshine writes: +

Re: [PATCH v2 3/5] t1500: avoid changing working directory outside of tests

Jeff King writes: > On Tue, May 17, 2016 at 04:48:33PM -0400, Eric Sunshine wrote: > >> On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano wrote: >> > Eric Sunshine writes: >> >> + git ${dir:+-C "$dir"} rev-parse --$o

Re: [PATCH v2 3/5] t1500: avoid changing working directory outside of tests

On Tue, May 17, 2016 at 5:52 PM, Jeff King wrote: > On Tue, May 17, 2016 at 04:48:33PM -0400, Eric Sunshine wrote: >> On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano wrote: >> > Eric Sunshine writes: >> >> + git

What's cooking in git.git (May 2016, #06; Tue, 17)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The 'master' branch now has 390

Re: [PATCH 04/14] connect: rewrite feature parsing to work on string_list

On Wed, 2016-05-04 at 13:13 -0700, Junio C Hamano wrote: > Stefan Beller writes: > > > Later on when we introduce the version 2 transport protocol, the > > capabilities will not be transported in one lone string but each > > s/lone/long/, I think. > > > capability will be

Re: [PATCH] fast-import: do not truncate exported marks file

Felipe Contreras writes: > Certain lines of the marks file might be corrupted (or the objects > missing due to a garbage collection), but that's no reason to truncate > the file and essentially destroy the rest of it. Hmm, so the issue is: - we use die_nicely()

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

On Tue, May 17, 2016 at 10:02:22PM +0200, Johannes Sixt wrote: > > Interesting. It replicates out of the box for me. > > "Out of the box" are the magic words. I usually compile with -O0, which > doesn't trigger the valgrind report. Heh, I meant that Noam's test worked out of the box. I also

Re: [PATCH v2 3/5] t1500: avoid changing working directory outside of tests

On Tue, May 17, 2016 at 04:48:33PM -0400, Eric Sunshine wrote: > On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano wrote: > > Eric Sunshine writes: > >> + git ${dir:+-C "$dir"} rev-parse --$o >actual && > > > > This is kosher POSIX,

[PATCH] fast-import: do not truncate exported marks file

Certain lines of the marks file might be corrupted (or the objects missing due to a garbage collection), but that's no reason to truncate the file and essentially destroy the rest of it. Ideally missing objects should not cause a crash, we could just skip them, but that's another patch.

Re: [PATCH v2 10/12] attr: convert git_all_attrs() to use "struct git_attr_check"

Junio C Hamano writes: > Given that one of the two expected callers, namely, "check-attr" and > Stefan's pathspec label magic, of this "alloc and then append" side > of the API wants to have an access to git_attr(name), I think > the function signature for this one should be

Re: [PATCH v2 3/5] t1500: avoid changing working directory outside of tests

On Tue, May 17, 2016 at 4:37 PM, Junio C Hamano wrote: > Eric Sunshine writes: >> + git ${dir:+-C "$dir"} rev-parse --$o >actual && > > This is kosher POSIX, but I vaguely recall some shells had trouble > with the SP between -C and

Re: [PATCH v2 3/5] t1500: avoid changing working directory outside of tests

Eric Sunshine writes: > + git ${dir:+-C "$dir"} rev-parse --$o >actual && This is kosher POSIX, but I vaguely recall some shells had trouble with the SP between -C and "$dir" in the past. Let's see if anybody screams; hopefully I am misremembering

Re: [PATCH v6 00/17] Port branch.c to use ref-filter's printing options

Karthik Nayak writes: > Sorry for that. > The only reason I haven't based it on 'master' is because it doesn't contain > 'f307218'. > > ➔ git branch --contains=f307218 > next > ref-filter It is not clear from the above what your local ref-filter contains beyond

Re: [RFC-PATCHv6 4/4] pathspec: allow querying for attributes

Stefan Beller writes: > On Mon, May 16, 2016 at 10:03 PM, Junio C Hamano wrote: >> When matching (i.e. the match_attrs() function), you would instead >> do >> >> path = xmemdupz(name, namelen); >> git_check_attr(path, item->attr_check); >>

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

Am 17.05.2016 um 21:45 schrieb Jeff King: On Tue, May 17, 2016 at 09:07:33PM +0200, Johannes Sixt wrote: Am 15.05.2016 um 15:05 schrieb Noam Postavsky: With a certain topology involving an octopus merge, git log --graph --oneline --all --color=never produces output which includes some ANSI

Re: [PATCH v6 05/17] ref-filter: move get_head_description() from branch.c

Karthik Nayak writes: > diff --git a/builtin/branch.c b/builtin/branch.c > index 2ecde53..141168d 100644 > --- a/builtin/branch.c > +++ b/builtin/branch.c > @@ -361,39 +361,6 @@ static void add_verbose_info(struct strbuf *out, struct > ref_array_item *item, >

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

On Tue, May 17, 2016 at 03:51:37PM -0400, Jeff King wrote: > On Tue, May 17, 2016 at 03:45:34PM -0400, Jeff King wrote: > > > Note that we set up f90, fa0, and fb0, but then pass fc0 into > > strbuf_write_column (and it has bogus color values). It looks like we're > > reading one past the end of

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

On Tue, May 17, 2016 at 03:45:34PM -0400, Jeff King wrote: > Note that we set up f90, fa0, and fb0, but then pass fc0 into > strbuf_write_column (and it has bogus color values). It looks like we're > reading one past the end of our array, but I haven't figured out where > or why. Looking at the

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

On Tue, May 17, 2016 at 09:07:33PM +0200, Johannes Sixt wrote: > Am 15.05.2016 um 15:05 schrieb Noam Postavsky: > > With a certain topology involving an octopus merge, git log --graph > > --oneline --all --color=never produces output which includes some ANSI > > escape code coloring. Attached is

[PATCH v2 0/5] modernize t1500

This is a re-roll of [1] which modernizes t1500 by updating tests to set up their own needed state rather than relying upon manipulation of global state. Changes since v1[1]: In v1 patch 1/6, which makes test_rev_parse() for-loop driven, the loop control has been moved to the top of the loop for

[PATCH v2 3/5] t1500: avoid changing working directory outside of tests

Ideally, each test should be responsible for setting up state it needs rather than relying upon transient global state. Toward this end, teach test_rev_parse() to accept a "-C " option to allow callers to instruct it explicitly in which directory its tests should be run. Take advantage of this new

[PATCH v2 2/5] t1500: test_rev_parse: facilitate future test enhancements

Tests run by test_rev_parse() are nearly identical; each invokes git-rev-parse with a single option and compares the result against an expected value. Such duplication makes it onerous to extend the tests since any change needs to be repeated in each test. Avoid the duplication by parameterizing

[PATCH v2 4/5] t1500: avoid setting configuration options outside of tests

Ideally, each test should be responsible for setting up state it needs rather than relying upon transient global state. Toward this end, teach test_rev_parse() to accept a "-b " option to allow callers to set "core.bare" explicitly or undefine it. Take advantage of this new option to avoid setting

[PATCH v2 1/5] t1500: be considerate to future potential tests

The final batch of git-rev-parse tests work against a non-local object database named repo.git. This is done by renaming .git to repo.git and pointing GIT_DIR at it, but the name is never restored to .git at the end of the script, which can be problematic for tests added in the future. Be more

[PATCH v2 5/5] t1500: avoid setting environment variables outside of tests

Ideally, each test should be responsible for setting up state it needs rather than relying upon transient global state. Toward this end, teach test_rev_parse() to accept a "-g " option to allow callers to specify the value of the GIT_DIR environment variable explicitly. Take advantage of this new

Re: [RFC-PATCHv6 4/4] pathspec: allow querying for attributes

On Mon, May 16, 2016 at 10:03 PM, Junio C Hamano wrote: > When matching (i.e. the match_attrs() function), you would instead > do > > path = xmemdupz(name, namelen); > git_check_attr(path, item->attr_check); > > to grab values for only attributes that matter to

Re: [BUG] A part of an edge from an octopus merge gets colored, even with --color=never

Am 15.05.2016 um 15:05 schrieb Noam Postavsky: With a certain topology involving an octopus merge, git log --graph --oneline --all --color=never produces output which includes some ANSI escape code coloring. Attached is a script to reproduce the problem (creates a git repository in subdir

Re: [PATCH v6 00/17] Port branch.c to use ref-filter's printing options

On Tue, May 17, 2016 at 11:22 PM, Junio C Hamano wrote: > Karthik Nayak writes: > >> Hello, sorry for the confusion, it's built on top of 'next' which contains >> f307218 (t6302: simplify non-gpg cases). The merge conflict is due to the >> commit made by

Re: [PATCH v4 2/2] convert: ce_compare_data() checks for a sha1 of a path

tbo...@web.de writes: > #define HASH_WRITE_OBJECT 1 > #define HASH_FORMAT_CHECK 2 > +#define HASH_CE_HAS_SHA1 4 How does one pronounce the words in this constant? Does it make a listener understand what this constant means? /* * We need a comment around here to say what these two *

Re: [PATCH v1 1/1] t6038; use crlf on all platforms

tbo...@web.de writes: > From: Torsten Bögershausen > > t6038 uses different code, depending if NATIVE_CRLF is set ot not. > When the native line endings are LF, merge.renormalize is not tested very > well. > Change the test to always use CRLF by setting core.eol=crlf. > --- >

Re: [RFC-PATCHv6 4/4] pathspec: allow querying for attributes

Stefan Beller writes: > I'll just drop support for values > in the first series. I do not think an exact string match to support :(attr:eol=crlf) is so bad. The "crazy stuff" aka over-engineering is when it goes beyond that, e.g. 'eol is set to one of these values" -- To

Re: GIT_INDEX_FILE relative path breaks in subdir

Junio C Hamano wrote: > Joey Hess writes: > > > Appears to be a bug in git. Seems that it's assuming GIT_INDEX_FILE is > > relative to the top of the worktree and not to the CWD. > > I think that has always been the case. You can always specify it as > relative to the top. Of

Re: [RFD PATCH 0/3] Free all the memory!

On Tue, May 17, 2016 at 11:16 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> So as a developer I wish we would close all leaks that are non-concerning. > > Valgrind suppression (and if you use other tools, suppression for > them) sounds like the way

Re: [RFD PATCH 0/3] Free all the memory!

Stefan Beller writes: > So as a developer I wish we would close all leaks that are non-concerning. Valgrind suppression (and if you use other tools, suppression for them) sounds like the way to go, I would think. Reducing false positive is a good goal; it helps to highlight

Re: [RFC-PATCHv6 4/4] pathspec: allow querying for attributes

On Tue, May 17, 2016 at 11:05 AM, Junio C Hamano wrote: > Stefan Beller writes: > >> I am not talking about crazy stuff here, but consider our own >> .gitattributes file: >> >> * whitespace=!indent,trail,space >> *.[ch] whitespace=indent,trail,space

[PATCH v3] Ignore dirty submodule states during stash

As stash does not know how to deal with submodules, it should not try to save/restore their states as it leads to redundant merge conflicts. Added test checks if 'stash pop' does not trigger merge conflicts in submodules. Signed-off-by: Vasily Titskiy --- git-stash.sh |

Re: [RFC-PATCHv6 4/4] pathspec: allow querying for attributes

Stefan Beller writes: > I am not talking about crazy stuff here, but consider our own > .gitattributes file: > > * whitespace=!indent,trail,space > *.[ch] whitespace=indent,trail,space > *.sh whitespace=indent,trail,space > > Now I want to search for > > "the

Re: [RFD PATCH 0/3] Free all the memory!

On Mon, May 16, 2016 at 8:41 PM, Eric Sunshine wrote: > On Mon, May 16, 2016 at 11:22 PM, Stefan Beller wrote: >> When using automated tools to find memory leaks, it is hard to distinguish >> between actual leaks and intentional non-cleanups at the

Re: [PATCH v6 00/17] Port branch.c to use ref-filter's printing options

Karthik Nayak writes: > Hello, sorry for the confusion, it's built on top of 'next' which contains > f307218 (t6302: simplify non-gpg cases). The merge conflict is due to the > commit made by you 1cca17df (Documentation: fix linkgit references). That is not "confusion",

Re: [RFC-PATCHv6 4/4] pathspec: allow querying for attributes

On Tue, May 17, 2016 at 10:34 AM, Junio C Hamano wrote: > Stefan Beller writes: > >>> Then while parsing ":(attr:VAR1=VAL1 -VAR2 VAR3...)path/to/dir/", >> >> This syntax is not pleasant to parse IMHO as it is not clear if the token >> after white space

Re: GIT_INDEX_FILE relative path breaks in subdir

Joey Hess writes: > Appears to be a bug in git. Seems that it's assuming GIT_INDEX_FILE is > relative to the top of the worktree and not to the CWD. I think that has always been the case. You can always specify it as relative to the top. Of course, you can use absolute. -- To

Re: [RFC-PATCHv6 4/4] pathspec: allow querying for attributes

Stefan Beller writes: >> Then while parsing ":(attr:VAR1=VAL1 -VAR2 VAR3...)path/to/dir/", > > This syntax is not pleasant to parse IMHO as it is not clear if the token > after white space (-VAR2 here) is another attribute or the next part of > the list of VAR1, ... Remove

Re: [Bug] git-log prints wrong unixtime with --date=format:%s

Michael Heerdegen writes: > the command > >git log --pretty=format:%ad --date=format:%s > > displays wrong unixtime values; apparently how much the printed value > differs from the expected value depends on the system's time zone and > whether daylight savings time

GIT_INDEX_FILE relative path breaks in subdir

joey@darkstar:/tmp>git init test Initialized empty Git repository in /tmp/test/.git/ joey@darkstar:/tmp>cd test joey@darkstar:/tmp/test>mkdir sub joey@darkstar:/tmp/test>cd sub joey@darkstar:/tmp/test/sub>GIT_INDEX_FILE=../.git/otherindex git write-tree fatal: Unable to create

Re: [PATCH v2] Ignore dirty submodule states during stash

The command does nothing, so it's not needed. There is also a typo in my patch description, so I'll resend it again with needed changes. -- Regards, Vasily Titskiy On Tue, May 17, 2016 at 1:04 PM, Junio C Hamano wrote: > Vasily Titskiy writes: > >>

Re: [PATCH v2] Ignore dirty submodule states during stash

Vasily Titskiy writes: > You're right, it's redundant here. Should I resubmit the path without this > line? I wasn't pointing out that it was not needed. I was only asking what it was meant to do. If you now think it shouldn't have been there, that merely means your code

Re: [RFC-PATCHv6 4/4] pathspec: allow querying for attributes

On Mon, May 16, 2016 at 10:03 PM, Junio C Hamano wrote: > > int attr_match_nr; > int attr_match_alloc; > struct attr_match { > struct git_attr *attr; > char *value; > enum attr_match_mode { >

Re: [PATCH v2 10/12] attr: convert git_all_attrs() to use "struct git_attr_check"

Junio C Hamano writes: > +struct git_attr_check *git_attr_check_alloc(void) > +{ > + return xcalloc(1, sizeof(struct git_attr_check)); > +} > + > +void git_attr_check_append(struct git_attr_check *check, const char *name) > +{ > + struct git_attr *attr; > + > + if

Re: [PATCH v2] Ignore dirty submodule states during stash

On Tue, May 17, 2016 at 9:16 AM, Vasily Titskiy wrote: > As stash does not know how to deal with submodules, > it should not try to save/restore their states > as it leads to redundant merge conflicts. > > Added test checks if 'stash pop' does not trigger merge conflics

Re: [RFC-PATCHv6 4/4] pathspec: allow querying for attributes

On Mon, May 16, 2016 at 9:23 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> + * attr:+val to find value set to true >> + * attr:-val to find a value set to false >> + * attr:!val to find a value that is not set >> + * (i.e. it is neither set as

Re: [PATCH v2] Ignore dirty submodule states during stash

Hi Junio, You're right, it's redundant here. Should I resubmit the path without this line? -- Regards, Vasily Titskiy On Tue, May 17, 2016 at 12:15 PM, Junio C Hamano wrote: > > Vasily Titskiy writes: > > > diff --git a/t/t3903-stash.sh

[PATCH v4 2/2] convert: ce_compare_data() checks for a sha1 of a path

From: Torsten Bögershausen To compare a file in working tree with the index, convert_to_git() is used, the the result is hashed and the hash value compared with ce->sha1. Deep down would_convert_crlf_at_commit() is invoked, to check if CRLF are converted or not: When a CRLF had

[PATCH v4 1/2] read-cache: factor out get_sha1_from_index() helper

From: Torsten Bögershausen Factor out the retrieval of the sha1 for a given path in read_blob_data_from_index() into the function get_sha1_from_index(). This will be used in the next commit, when convert.c can do the analyze for "text=auto" without slurping the whole blob into

[PATCH v4 0/2] CRLF: ce_compare_data() checks for a sha1 of a path

From: Torsten Bögershausen Break up the old 10/10 series about CLRF handling into smaller series. This is a small bugfix, when merge.renormalize is used with core.autocrlf (and no attributes are set). Prepare the refactoring to use the streaming interface. Torsten Bögershausen

Re: [PATCH v2] Ignore dirty submodule states during stash

Vasily Titskiy writes: > diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh > index 2142c1f..1be62f3 100755 > --- a/t/t3903-stash.sh > +++ b/t/t3903-stash.sh > @@ -731,4 +731,38 @@ test_expect_success 'stash list --cc shows combined > diff' ' > test_cmp expect actual > '

[PATCH v1 1/1] t6038; use crlf on all platforms

From: Torsten Bögershausen t6038 uses different code, depending if NATIVE_CRLF is set ot not. When the native line endings are LF, merge.renormalize is not tested very well. Change the test to always use CRLF by setting core.eol=crlf. --- Broke the 10/10 series into smaller

[PATCH v2] Ignore dirty submodule states during stash

As stash does not know how to deal with submodules, it should not try to save/restore their states as it leads to redundant merge conflicts. Added test checks if 'stash pop' does not trigger merge conflics in submodules. Signed-off-by: Vasily Titskiy --- git-stash.sh | 2

Re: [BUG] t9801 and t9803 broken on next

On Tue, May 17, 2016 at 10:07:16AM +0200, Lars Schneider wrote: > I think that is pretty much the problem. Here is what is happening: > > 1. git-p4 imports all changelists for the "main" branch > > 2. git-p4 starts to import a second branch and creates a fast-import > "progress

Re: [RFD PATCH 0/3] Free all the memory!

Eric Sunshine wrote: > On Mon, May 16, 2016 at 11:22 PM, Stefan Beller wrote: > > When using automated tools to find memory leaks, it is hard to distinguish > > between actual leaks and intentional non-cleanups at the end of the program, > > such that

Re: [BUG] t9801 and t9803 broken on next

Lars Schneider wrote: > I am no expert in "fast-import". Does anyone have a few hints how to > proceed? I don't know fast-import or the C internals of git well at all, either. But capturing the exact input to fast-import (using tee) would be useful for non-p4 users to

Re: [RFD PATCH 0/3] Free all the memory!

Stefan Beller writes: > The end goal of this (unfinished) series is to close all intentional memory > leaks when enabling the -DFREE_ALL_MEMORY switch. This is just > demonstrating how the beginning of such a series could look like. One potential issue with this is: if all

Re: [BUG] t9801 and t9803 broken on next

On 14 May 2016 at 19:15, Junio C Hamano wrote: > Lars Schneider writes: > >>> On 13 May 2016, at 18:37, Junio C Hamano wrote: >>> >>> Are you saying that "git p4" itself breaks unless fast-import always >>> writes a new (tiny)

Re: [BUG] t9801 and t9803 broken on next

> On 14 May 2016, at 20:15, Junio C Hamano wrote: > > Lars Schneider writes: > >>> On 13 May 2016, at 18:37, Junio C Hamano wrote: >>> >>> Are you saying that "git p4" itself breaks unless fast-import always >>> writes a new

Re: [PATCH v6 00/17] Port branch.c to use ref-filter's printing options

On Tue, May 17, 2016 at 3:42 AM, Junio C Hamano wrote: > > Karthik Nayak writes: > > > This is part of unification of the commands 'git tag -l, git branch -l > > and git for-each-ref'. This ports over branch.c to use ref-filter's > > printing options. >