d | head -3
README.md
15:56:git
18:20:git
By using show_line_header(), 'git grep --only-matching' correctly
respects the '--header' option:
$ git grep -on --column --heading git -- README.md | head -4
README.md
15:56:git
18:20:git
19:16:git
Signed-of
On Sun, May 06, 2018 at 08:03:01PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Sun, May 06 2018, Martin Ågren wrote:
>
> > On 5 May 2018 at 04:43, Taylor Blau wrote:
> >> Take advantage of 'git-grep(1)''s new option, '--column' in order to
>
On Sat, May 05, 2018 at 08:15:03AM +0200, Duy Nguyen wrote:
> On Sat, May 5, 2018 at 4:43 AM, Taylor Blau wrote:
> > Teach 'git-grep(1)' a new option, '--column', to show the column
> > number of the first match on a non-context line.
>
> Why? Or put it
On Sun, May 06, 2018 at 07:56:42PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, May 05 2018, Taylor Blau wrote:
>
>
> > + test_expect_success "grep -w $L (with --{line,column}-number)" '
>
> It's now --column in v4 but this still refers to v3
On Mon, May 07, 2018 at 11:13:12PM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
> > index 18b494731f..5409a24399 100644
> > --- a/Documentation/git-grep.txt
> > +++ b/Documentation/g
On Sat, May 05, 2018 at 03:30:51AM -0400, Eric Sunshine wrote:
> On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote:
> > Teach 'git-grep(1)' how to print a line header multiple times from
> > show_line() in preparation for it learning '--only-matching'.
> >
On Sat, May 05, 2018 at 03:36:12AM -0400, Eric Sunshine wrote:
> On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote:
> > Teach GNU grep(1)'s '-o' ('--only-matching') to 'git-grep'. This option
> > prints only the matching components of each l
On Fri, May 04, 2018 at 12:48:21AM +0300, Paul-Sebastian Ungureanu wrote:
> Hello everybody,
>
> The community bonding period started. It is well known that for a greater
> rate of success, it is recommended to send weekly reports regarding project
> status. But, what would be a good form for such
ic-inbox.org/git/CACsJy8BdJ0=gwzqvfsqy-vjtzvt4uznzrapyxryxx2wnzal...@mail.gmail.com
[3]:
https://public-inbox.org/git/20bc9baf-a85e-f00e-859e-e796ab432...@talktalk.net
[4]: https://public-inbox.org/git/87efioy8f9@evledraar.gmail.com
[5]: https://public-inbox.org/git/xmqqk1sfpn9j@gitster
To support git-grep(1)'s new option, '--column', document and teach
grep.c how to interpret relevant configuration options, similar to those
associated with '--line-number'.
Signed-off-by: Taylor Blau
---
Documentation/config.txt | 5 +
Documentation/git
To support showing the matched column when calling 'git-grep(1)', teach
'grep_opt' the normal set of options to configure the default behavior
and colorization of this feature.
Signed-off-by: Taylor Blau
---
grep.c | 3 +++
grep.h | 2 ++
2 files changed, 5 insertions(+)
d
Take advantage of 'git-grep(1)''s new option, '--column' in order to
teach Peff's 'git-jump' script how to jump to the correct column for any
given match.
'git-grep(1)''s output is in the correct format for Vim's jump list, so
no
To prepare for 'git grep' learning '--column', teach grep.c's
show_line() how to show the column of the first match on non-context
line.
Signed-off-by: Taylor Blau
---
grep.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --gi
lineNumber has casing that is inconsistent with surrounding options,
like color.grep.matchContext, and color.grep.matchSelected. Re-case this
documentation in order to be consistent with the text around it, and to
ensure that new entries are consistent, too.
Signed-off-by: Taylor Blau
s similar additional
scripting capabilities.
For example:
$ git grep -n --column foo | head -n3
.clang-format:51:14:# myFunction(foo, bar, baz);
.clang-format:64:7:# int foo();
.clang-format:75:8:# void foo()
Signed-off-by: Taylor Blau
---
Documentation/git-grep.txt | 6 +-
builtin/grep.c
tarting and ending offset from the beginning of
the line. This additional argument has no effect when opt->extended is
non-zero.
We will later pass the starting offset from 'regmatch_t *' to
show_line() in order to display the column number of the first match.
Signed-off-by: Taylor B
On Wed, May 09, 2018 at 06:17:20PM +0200, Duy Nguyen wrote:
> On Wed, May 9, 2018 at 4:13 AM, Taylor Blau wrote:
> > diff --git a/builtin/grep.c b/builtin/grep.c
> > index 5f32d2ce84..f9f516dfc4 100644
> > --- a/builtin/grep.c
> > +++ b/builtin/grep.c
> > @@ -829,
On Wed, May 09, 2018 at 11:41:02AM +0100, Phillip Wood wrote:
> Hi Taylor
>
> On 09/05/18 03:13, Taylor Blau wrote:
> > Teach 'git-grep(1)' a new option, '--column', to show the column
> > number of the first match on a non-context line. This makes it po
On Wed, May 09, 2018 at 07:26:57PM +0200, Martin Ågren wrote:
> On 9 May 2018 at 12:41, Phillip Wood wrote:
> > On 09/05/18 03:13, Taylor Blau wrote:
> >>
> >> +--column::
> >> + Prefix the 1-indexed byte-offset of the first match on non-context
>
On Tue, May 08, 2018 at 01:25:17PM -0400, Jeff King wrote:
> On Sat, May 05, 2018 at 08:49:43AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > > +test_expect_success 'grep --only-matching --heading' '
> > > + git grep --only-matching --heading --line-number --column mmap file
> > > >actual &&
> > > +
appily accept lines with or without
columnar information, and Vim will accept it as-is.
So, let's support --column and only die() when also given
--invert-match. When we don't have a good answer, print nothing.
Thanks,
Taylor
Taylor Blau (7):
Documentation/config.txt: camel-case lineNu
To support showing the matched column when calling 'git-grep(1)', teach
'grep_opt' the normal set of options to configure the default behavior
and colorization of this feature.
Signed-off-by: Taylor Blau
---
grep.c | 3 +++
grep.h | 2 ++
2 files changed, 5 insertions(+)
d
tarting and ending offset from the beginning of
the line. This additional argument has no effect when opt->extended is
non-zero.
We will later pass the starting offset from 'regmatch_t *' to
show_line() in order to display the column number of the first match.
Signed-off-by: Taylor B
lineNumber has casing that is inconsistent with surrounding options,
like color.grep.matchContext, and color.grep.matchSelected. Re-case this
documentation in order to be consistent with the text around it, and to
ensure that new entries are consistent, too.
Signed-off-by: Taylor Blau
To prepare for 'git grep' learning '--column', teach grep.c's
show_line() how to show the column of the first match on non-context
line.
Signed-off-by: Taylor Blau
---
grep.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --gi
s similar additional
scripting capabilities.
For example:
$ git grep -n --column foo | head -n3
.clang-format:51:14:# myFunction(foo, bar, baz);
.clang-format:64:7:# int foo();
.clang-format:75:8:# void foo()
Signed-off-by: Taylor Blau
---
Documentation/git-grep.txt | 7 ++-
builtin/grep.c
Take advantage of 'git-grep(1)''s new option, '--column' in order to
teach Peff's 'git-jump' script how to jump to the correct column for any
given match.
'git-grep(1)''s output is in the correct format for Vim's jump list, so
no
To support git-grep(1)'s new option, '--column', document and teach
grep.c how to interpret relevant configuration options, similar to those
associated with '--line-number'.
Signed-off-by: Taylor Blau
---
Documentation/config.txt | 5 +
Documentation/git
ementation.
For now, show_line_header() provides no benefit over the change before
this patch. The following patch will conditionally call
show_line_header() multiple times per invocation to show_line(), which
is the desired benefit of this change.
Signed-off-by: Taylor Bl
hes, we keep track of a relative offset from the beginning of the
line and increment 'cno' in subsequent calls to show_line_header() when
the expression is not extended. In the extended case, we do not do this,
because the column of the first match is undefined, thus relative
offsets ar
[1]: https://public-inbox.org/git/20180510064014.ga31...@sigill.intra.peff.net
[2]:
https://public-inbox.org/git/capig+csrjww4-7vj6wk8aofnb20bqucsooysjdpci1r5vb8...@mail.gmail.com
[3]:
https://public-inbox.org/git/capig+crbbz+qtqgiw_wq9e-groa-wtevp1vcrqmj5yqj8ty...@mail.gmail.com
Tayl
On Thu, May 10, 2018 at 09:04:34AM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > This check we should retain and change the wording to mention '--and',
> > '--or', and '--not' specifically.
>
> Why are these problematic in the fir
On Sat, May 12, 2018 at 02:08:48PM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> >> $ git grep -v second
> >> $ git grep --not -e second
> >>
> >> may hit all lines in this message (except for the obvious two
> >> lines), b
On Sat, May 12, 2018 at 03:07:04PM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > I re-read your note and understand more clearly now what your suggestion
> > is. To ensure that we're in agreement, do you mean:
> >
> > 1. '--column -v' w
much of a reviewer. Would it be OK if I sent this a
new series entirely and we abandon this thread?
On Fri, May 18, 2018 at 03:27:44PM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > * `git grep --and -e foo -e bar`. This binary operation should recur
> > on its
On Fri, May 18, 2018 at 03:27:04PM -0700, Jeff King wrote:
> If you run "config --blob" outside of a repository, then we
> eventually try to resolve the blob name and hit a BUG().
> Let's catch this earlier and provide a useful message.
I think that this approach is sensible. Let's (1) fix a SIGSE
On Fri, May 18, 2018 at 02:50:21PM -0700, Taylor Blau wrote:
> [...]
>
> > Another might be to pick "foo" in the first and "bar" in the second
> > line, as that is the "first hit" on the line, which is consistent
> > with how "git grep -e
On Wed, May 30, 2018 at 03:38:09PM +0900, Junio C Hamano wrote:
> * tb/grep-column (2018-05-14) 7 commits
> - contrib/git-jump/git-jump: jump to match column in addition to line
> - grep.c: add configuration variables to show matched option
> - builtin/grep.c: add '--column' option to 'git-grep(
On Wed, May 30, 2018 at 09:09:08AM -0700, Taylor Blau wrote:
> [...]
>
> I have these patches mostly updated on my copy (available at
> https://github.com/ttaylorr/git/compare/tb/grep-column) but am out of
> the office for the next week, so I will polish and send these on June
&g
still quite new to working on Git itself.
Thanks,
Taylor
Taylor Blau (4):
builtin/config: introduce `--default`
Documentation: list all type specifiers in config prose
config.c: introduce 'git_config_color' to parse ANSI colors
builtin/config: introduce `--color` type
1048576
In subsequent commits, we will offer `--color`, which (in conjunction
with `--default`) will be sufficient to replace `--get-color`.
Signed-off-by: Taylor Blau
---
Documentation/git-config.txt | 4 ++
builtin/config.c | 19 +++
t/t1310-config-default.sh| 119
In preparation for adding `--color` to the `git-config(1)` builtin,
let's introduce a color parsing utility, `git_config_color` in a similar
fashion to `git_config_`.
Signed-off-by: Taylor Blau
---
config.c | 10 ++
config.h | 1 +
2 files changed, 11 insertions(+)
diff --
pares for the new type specifier `--color`, so that
this section will not lag behind when yet more new specifiers are added.
Signed-off-by: Taylor Blau
---
Documentation/git-config.txt | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-config.
et-color` alone.
Signed-off-by: Taylor Blau
---
Documentation/git-config.txt | 10 +++---
builtin/config.c | 17 +
t/t1300-repo-config.sh | 16
3 files changed, 40 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-config.txt b/Do
On Mon, Mar 05, 2018 at 06:17:25PM -0800, Taylor Blau wrote:
> Attached is a patch series to introduce `--default` and `--color` to the
> `git-config(1)` builtin with the aim of introducing a consistent interface to
> replace `--get-color`.
This series draws significant inspiration from
ding to the
mailing list, so this process is entirely new to me. My current focus is helping
maintain Git LFS [1] at GitHub. If I have made any mistakes in formatting these
patches or sending them, please let me know :-).
Thank you in advance.
--
- Taylor
[1]: https://git-lfs.github.com
Taylor
ers to test that non-trailers aren't
shown using "%(trailers:only)".
- Add a multi-line trailer to ensure that trailers are unfolded correctly
using "%(trailers:unfold)".
Signed-off-by: Taylor Blau
---
t/t6300-for-each-ref.sh | 11 +--
1 file changed, 9
as "%(trailers:unfold,only)" or
"%(trailers:only,unfold)".
This change disambiguates between "top-level" arguments, and arguments given to
the trailers atom itself. It is consistent with the behavior of "%(upstream)"
and "%(push)" atoms.
Signed-
at: trailers_atom_parser expects NULL when no arguments are given (see:
`parse_ref_filter_atom`). To simulate this behavior without teaching
trailers_atom_parser to accept strings with length zero, conditionally pass
NULL to trailers_atom_parser if the arguments portion of the argument to
%(co
at ref trailers correctly using
`format_trailer_from_commit`.
Signed-off-by: Taylor Blau
---
ref-filter.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/ref-filter.c b/ref-filter.c
index 467c0279c..84f14093c 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -82,6 +82,7 @@ static s
In preparation to support additional sub-arguments given to the "%(trailers)"
atom, use 'format_trailers_from_commit' in order to format trailers in the
desired manner.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 6 +-
ref-filter.c
Hi,
Attached is v2 of my patch-set "Support %(trailers) arguments in
for-each-ref(1)".
It includes the following changes since v1:
* Accept "empty-sub-argument" lists, like %(contents:trailers:).
* Fix incorrect tabs/spaces formatting in t6300.
* Modern-ize code fencing in Documentation/
as "%(trailers:unfold,only)" or
"%(trailers:only,unfold)".
This change disambiguates between "top-level" arguments, and arguments
given to the trailers atom itself. It is consistent with the behavior of
"%(upstream)" and "%(push)" atoms.
Signed-off
s the designated way to
dig out trailers information.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 03e187a10..6b38d9a22 100644
at: trailers_atom_parser expects NULL when no arguments are given
(see: `parse_ref_filter_atom`). To simulate this behavior without
teaching trailers_atom_parser to accept strings with length zero,
conditionally pass NULL to trailers_atom_parser if the arguments portion
of the argument to %(contents) is
Fill trailer_opts with "unfold" and "only" to match the sub-arguments
given to the "%(trailers)" atom. Then, let's use the filled trailer_opts
instance with 'format_trailers_from_commit' in order to format trailers
in the desired manner.
Signed-off-by:
ers to test that non-trailers
aren't shown using "%(trailers:only)".
- Add a multi-line trailer to ensure that trailers are unfolded
correctly using "%(trailers:unfold)".
Signed-off-by: Taylor Blau
---
t/t6300-for-each-ref.sh | 11 +--
1 file changed, 9 insert
t;-style fencing instead.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 6b38d9a22..b6492820b 100644
--- a/Documentation/git-for-
Hi,
Attached is v3 of my patch-set "Support %(trailers) arguments in
for-each-ref(1)".
It includes all of the changes in V2:
> * Accept "empty-sub-argument" lists, like %(contents:trailers:).
>
> * Fix incorrect tabs/spaces formatting in t6300.
>
> * Modern-ize code fencing in Documentation
as "%(trailers:unfold,only)" or
"%(trailers:only,unfold)".
This change disambiguates between "top-level" arguments, and arguments
given to the trailers atom itself. It is consistent with the behavior of
"%(upstream)" and "%(push)" atoms.
Signed-off
ers to test that non-trailers
aren't shown using "%(trailers:only)".
- Add a multi-line trailer to ensure that trailers are unfolded
correctly using "%(trailers:unfold)".
Signed-off-by: Taylor Blau
---
t/t6300-for-each-ref.sh | 11 +--
1 file changed, 9 insert
s the designated way to
dig out trailers information.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 03e187a10..6b38d9a22 100644
at: trailers_atom_parser expects NULL when no arguments are given
(see: `parse_ref_filter_atom`). To simulate this behavior without
teaching trailers_atom_parser to accept strings with length zero,
conditionally pass NULL to trailers_atom_parser if the arguments portion
of the argument to %(contents) is
Fill trailer_opts with "unfold" and "only" to match the sub-arguments
given to the "%(trailers)" atom. Then, let's use the filled trailer_opts
instance with 'format_trailers_from_commit' in order to format trailers
in the desired manner.
Signed-off-by:
t;-style fencing instead.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 6b38d9a22..b6492820b 100644
--- a/Documentation/git-for-
Hi,
Attached is the fourth revision of my patch-set "Support %(trailers)
arguments in for-each-ref(1)".
It includes the following changes since v3:
* Teach unfold() to unfold multiple lines.
* Rebase patches to apply on top of master.
Thanks in advance, and thanks for all of your help thus
Fill trailer_opts with "unfold" and "only" to match the sub-arguments
given to the "%(trailers)" atom. Then, let's use the filled trailer_opts
instance with 'format_trailers_from_commit' in order to format trailers
in the desired manner.
Signed-off-by:
t;-style fencing instead.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 323ce07de..1279b9733 100644
--- a/Documentation/git-for-
ers to test that non-trailers
aren't shown using "%(trailers:only)".
- Add a multi-line trailer to ensure that trailers are unfolded
correctly using "%(trailers:unfold)".
Signed-off-by: Taylor Blau
---
t/t6300-for-each-ref.sh | 11 +--
1 file changed, 9 insert
s the designated way to
dig out trailers information.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 66b4e0a40..323ce07de 100644
at: trailers_atom_parser expects NULL when no arguments are given
(see: `parse_ref_filter_atom`). To simulate this behavior without
teaching trailers_atom_parser to accept strings with length zero,
conditionally pass NULL to trailers_atom_parser if the arguments portion
of the argument to %(contents) is
as "%(trailers:unfold,only)" or
"%(trailers:only,unfold)".
This change disambiguates between "top-level" arguments, and arguments
given to the trailers atom itself. It is consistent with the behavior of
"%(upstream)" and "%(push)" atoms.
Signed-off
On Mon, Oct 02, 2017 at 08:55:53AM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > "'"- (single-quote) styled code fencing is no longer considered modern
> > within the "Documentation/" subtree.
> >
> > In preparation for adding add
Hi,
Attached is the fifth revision of my patch-set "Support %(trailers)
arguments in for-each-ref(1)".
It includes the following changes since v4:
* Clarified "ref-filter.c: parse trailers arguments with %(contents)
atom" to include reasoning for passing NULL as "" empty string in
cont
ers to test that non-trailers
aren't shown using "%(trailers:only)".
- Add a multi-line trailer to ensure that trailers are unfolded
correctly using "%(trailers:unfold)".
Signed-off-by: Taylor Blau
---
t/t6300-for-each-ref.sh | 11 +--
1 file changed, 9 insert
as "%(trailers:unfold,only)" or
"%(trailers:only,unfold)".
This change disambiguates between "top-level" arguments, and arguments
given to the trailers atom itself. It is consistent with the behavior of
"%(upstream)" and "%(push)" atoms.
Signed-o
s the designated way to
dig out trailers information.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 66b4e0a40..323ce07de 100644
Fill trailer_opts with "unfold" and "only" to match the sub-arguments
given to the "%(trailers)" atom. Then, let's use the filled trailer_opts
instance with 'format_trailers_from_commit' in order to format trailers
in the desired manner.
Signed-off-by:
aching trailers_atom_parser to
accept strings with length zero, conditionally pass NULL to
trailers_atom_parser if the arguments portion of the argument to
%(contents) is empty.
Signed-off-by: Taylor Blau
---
ref-filter.c| 7 ---
t/t6300-for-each-ref.sh | 37
t;-style quoting instead.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 323ce07de..1279b9733 100644
--- a/Documentation/git-for-
On Mon, Oct 02, 2017 at 01:05:07AM -0400, Jeff King wrote:
> On Sun, Oct 01, 2017 at 06:00:25PM +0900, Junio C Hamano wrote:
>
> > Taylor Blau writes:
> >
> > > diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh
> > > index 2a9fcf713..2bd0c5da7
On Mon, Oct 02, 2017 at 01:03:51AM -0400, Jeff King wrote:
> On Sun, Oct 01, 2017 at 05:33:04PM -0700, Taylor Blau wrote:
>
> > The %(contents) atom takes a contents "field" as its argument. Since
> > "trailers" is one of those fields, extend contents
On Mon, Oct 02, 2017 at 01:51:11PM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > @@ -212,9 +212,10 @@ static void contents_atom_parser(const struct
> > ref_format *format, struct used_at
> > atom->u.contents.option = C_SIG;
> >
Hi,
Attached is the sixth revision of my patch-set "Support %(trailers)
arguments in for-each-ref(1)".
In includes the following changes since v5:
* Added an additional patch to change t4205 to harden `unfold()`
against multi-line trailer folding.
* Added a missing parameter call in ref
as "%(trailers:unfold,only)" or
"%(trailers:only,unfold)".
This change disambiguates between "top-level" arguments, and arguments
given to the trailers atom itself. It is consistent with the behavior of
"%(upstream)" and "%(push)" atoms.
Signed-o
s the designated way to
dig out trailers information.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 66b4e0a40..323ce07de 100644
for adding subsequent tests in t6300 that test similar
behavior in `git-for-each-ref(1)`, let's harden t4205 (and make it
consistent with the changes in t6300) by ensuring that 3 or more
line folded trailers are unfolded correctly.
Signed-off-by: Taylor Blau
---
t/t4205-log-pretty-formats.sh
aching trailers_atom_parser to
accept strings with length zero, conditionally pass NULL to
trailers_atom_parser if the arguments portion of the argument to
%(contents) is empty.
Signed-off-by: Taylor Blau
---
ref-filter.c| 7 ---
t/t6300-for-each-ref.sh | 37
t;-style quoting instead.
Signed-off-by: Taylor Blau
---
Documentation/git-for-each-ref.txt | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index 323ce07de..1279b9733 100644
--- a/Documentation/git-for-
Fill trailer_opts with "unfold" and "only" to match the sub-arguments
given to the "%(trailers)" atom. Then, let's use the filled trailer_opts
instance with 'format_trailers_from_commit' in order to format trailers
in the desired manner.
Signed-off-by:
ers to test that non-trailers
aren't shown using "%(trailers:only)".
- Add a multi-line trailer to ensure that trailers are unfolded
correctly using "%(trailers:unfold)".
Signed-off-by: Taylor Blau
---
t/t6300-for-each-ref.sh | 11 +--
1 file changed, 9 insert
Hi,
Attached is a one-long patch series to un-distinguish between atoms
without sub-arguments ("%(refname)") and atoms with empty sub-argument
lists ("%(refname:)").
This addresses a user-experience issue that Peff points out:
> Doh, that string_list behavior is what I was missing in my earlier
empty
string), this makes handling empty sub-argument strings non-ergonomic.
Let's fix this by assuming that atom parser implementations don't care
about distinguishing between the empty string "%(refname:)" and no
sub-arguments "%(refname)".
Signed-off-
On Mon, Oct 02, 2017 at 02:51:00AM -0400, Jeff King wrote:
> > diff --git a/ref-filter.c b/ref-filter.c
> > index 43ed10a5e..6c26b4733 100644
> > --- a/ref-filter.c
> > +++ b/ref-filter.c
> > @@ -212,9 +212,10 @@ static void contents_atom_parser(const struct
> > ref_format *format, struct used_at
On Mon, Oct 02, 2017 at 09:15:00PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Thanks. t6300 seems to show that %(contents:trailers:unfold) does
> > not quite work, among other things.
> >
> > https://travis-ci.org/git/git/jobs/282126607#L3658
> >
> > I didn't have a chance to l
empty
string), this makes handling empty sub-argument strings non-ergonomic.
Let's fix this by assuming that atom parser implementations don't care
about distinguishing between the empty string "%(refname:)" and no
sub-arguments "%(refname)".
Signed-off-by: Taylor Bla
On Mon, Oct 02, 2017 at 02:43:35AM -0400, Jeff King wrote:
> On Sun, Oct 01, 2017 at 10:53:11PM -0700, Taylor Blau wrote:
>
> > Peff points out that different atom parsers handle the empty
> > "sub-argument" list differently. An example of this is the format
>
On Tue, Oct 03, 2017 at 08:55:01AM +0900, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > The above does a nice job of explaining
> >
> > - what this change is going to do
> > - how it's good for the internal code structure / maintainability
> >
> > What it doesn't tell me about is why the
On Wed, Oct 04, 2017 at 05:46:21PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> >> - pretty.c: delimit "%(trailers)" arguments with ","
> >>
> >> "git for-each-ref --format=..." learned a new format element,
> >> %(trailers), to show only the commit log trailer part of the log
> >> mes
ble check that these acks are real, but I'd still wait for a few
> days for people who expressed their Acks but your scan missed, or
> those who wanted to give their Acks but forgot to do so, to raise
> their hands on this thread.
I'd be quite pleased to join those above with my stron
401 - 500 of 500 matches
Mail list logo
