Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

s in the checkout by the point I see Git ask for the status of an item more than once", then Git _cannot_ ask for the status of a delayed item while there are still more items to checkout. This could be OK, so long as the protocol commits to it and documents this behavior. What are your thoughts? -- Thanks, Taylor Blau ttayl...@github.com

Re: [PATCH v1] convert: add "status=delayed" to filter process protocol

that batch delayed items into groups. In particular, if the batch size is `N`, and Git sends `2N-1` items, the second batch will be under-filled. The filter on the other end needs some mechanism to send the second batch, even though it hasn't hit max capacity. Specifically, this is how Git LFS implements object transfers for data it does not have locally, but I'm sure that this sort of functionality would be useful for other filter implementations as well. -- Thanks, Taylor Blau ttayl...@github.com

Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

in e.g TCP) > > > > The number of outstanding blobs is may be less important, and it is more > > important to monitor the number of bytes we keep in memory in some way. > > > > Something like "we set a limit to 500K of out standng data", once we are > > above the limit, don't send any new blobs. > > I don't expect the filter to keep everything in memory. If there is no memory > anymore then I expect the filter to spool to disk. This keeps the protocol > simple. > If this turns out to be not sufficient then we could improve that later, too. Agree. -- Thanks, Taylor Blau

Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

ing to remove this command and instead allow the filter to send readied blobs in sequence after all unique checkout entries had been sent from Git to the filter. But I think this allows approach allows us more flexibility, and isn't that much extra complication or bytes across the pipe. -- Thanks, Taylor Blau

Re: [PATCH v3 4/4] convert: add "status=delayed" to filter process protocol

nks for correcting my thinking here. I ran a simple command to get the longest path names in a large repository, as: $ find . -type f | awk '{ print length($1) }' | sort -r -n | uniq -c And found a few files close to the 200 character mark as the longest pathnames in the repository. I think 50k files at 1k bytes per pathname is quite enough head-room :-). -- Thanks, Taylor Blau

Re: [PATCH v4 4/4] convert: add "status=delayed" to filter process protocol

I have no remaining concerns about the protocol specification in terms of implementing a filter with this capability.

Re: [PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers

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

[PATCH 0/5] Support %(trailers) arguments in for-each-ref(1)

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 Blau

[PATCH 2/5] t6300: refactor %(trailers) tests

t 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 <m...@ttaylorr.com> --- t/t6300-for-each-ref.sh | 11 +-- 1 file c

[PATCH 1/5] pretty.c: delimit "%(trailers)" arguments with ","

uot;%(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-by

[PATCH v3 1/6] pretty.c: delimit "%(trailers)" arguments with ","

uot;%(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)&

[PATCH v3 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

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

[PATCH v3 5/6] ref-filter.c: use trailer_opts to format trailers

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:

[PATCH v3 4/6] doc: use modern "`"-style code fencing

e fencing instead. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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/Docu

[PATCH v3 2/6] t6300: refactor %(trailers) tests

t 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 <m...@ttaylorr.com> --- t/t6300-for-each-ref.sh | 11 +-- 1 file c

[PATCH v3 3/6] doc: 'trailers' is the preferred way to format trailers

information. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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 --- a/Documentati

[PATCH 5/5] ref-filter.c: parse trailers arguments with %(contents) atom

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

[PATCH 3/5] ref-filter.c: add trailer options to used_atom

f trailers correctly using `format_trailer_from_commit`. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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

[PATCH 4/5] ref-filter.c: use trailer_opts to format trailers

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 <m...@ttaylorr.com> --- Documentation/git-for-each-ref.txt | 6

Re: [PATCH v2 0/6] Support %(trailers) arguments in for-each-ref(1)

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

[PATCH v2 0/6] Support %(trailers) arguments in for-each-ref(1)

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

[PATCH v2 1/6] pretty.c: delimit "%(trailers)" arguments with ","

uot;%(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)&

[PATCH v2 3/6] doc: 'trailers' is the preferred way to format trailers

information. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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 --- a/Documentati

[PATCH v2 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

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

[PATCH v2 5/6] ref-filter.c: use trailer_opts to format trailers

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:

[PATCH v2 2/6] t6300: refactor %(trailers) tests

t 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 <m...@ttaylorr.com> --- t/t6300-for-each-ref.sh | 11 +-- 1 file c

[PATCH v2 4/6] doc: use modern "`"-style code fencing

e fencing instead. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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/Docu

[PATCH v4 1/6] pretty.c: delimit "%(trailers)" arguments with ","

uot;%(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)&

[PATCH v4 5/6] ref-filter.c: use trailer_opts to format trailers

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:

[PATCH v4 4/6] doc: use modern "`"-style code fencing

e fencing instead. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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/Docu

[PATCH v4 2/6] t6300: refactor %(trailers) tests

t 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 <m...@ttaylorr.com> --- t/t6300-for-each-ref.sh | 11 +-- 1 file c

Re: [PATCH v4 0/6] Support %(trailers) arguments in for-each-ref(1)

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

[PATCH v4 3/6] doc: 'trailers' is the preferred way to format trailers

information. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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 --- a/Documentati

[PATCH v4 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

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

Re: [PATCH v6 0/7] Support %(trailers) arguments in for-each-ref(1)

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

Re: [PATCH v4 4/6] doc: use modern "`"-style code fencing

On Mon, Oct 02, 2017 at 08:55:53AM +0900, Junio C Hamano wrote: > Taylor Blau <m...@ttaylorr.com> writes: > > > "'"- (single-quote) styled code fencing is no longer considered modern > > within the "Documentation/" subtree. > > > > In prepa

Re: [PATCH v5 0/6] Support %(trailers) arguments in for-each-ref(1)

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

Re: [PATCH 4/5] ref-filter.c: use trailer_opts to format trailers

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 <m...@ttaylorr.com> writes: > > > > > diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh > > > index

Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

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

Re: [PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

On Mon, Oct 02, 2017 at 01:51:11PM +0900, Junio C Hamano wrote: > Taylor Blau <m...@ttaylorr.com> writes: > > > @@ -212,9 +212,10 @@ static void contents_atom_parser(const struct > > ref_format *format, struct used_at > > atom->u.contents.option = C_

[PATCH 0/1] ref-filter.c: pass empty-string as NULL to atom parsers

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

[PATCH v5 2/6] t6300: refactor %(trailers) tests

t 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 <m...@ttaylorr.com> --- t/t6300-for-each-ref.sh | 11 +-- 1 file c

[PATCH v5 1/6] pretty.c: delimit "%(trailers)" arguments with ","

uot;%(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)&

[PATCH v5 3/6] doc: 'trailers' is the preferred way to format trailers

information. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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 --- a/Documentati

[PATCH v5 5/6] ref-filter.c: use trailer_opts to format trailers

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:

[PATCH v5 6/6] ref-filter.c: parse trailers arguments with %(contents) atom

g 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 <m...@ttaylorr.com> --- ref-filter.c| 7 --- t/t6300-for-each-ref.sh | 37

[PATCH v5 4/6] doc: use modern "`"-style code quoting

e quoting instead. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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/Docu

[PATCH v6 6/7] ref-filter.c: use trailer_opts to format trailers

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:

[PATCH v6 5/7] t6300: refactor %(trailers) tests

t 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 <m...@ttaylorr.com> --- t/t6300-for-each-ref.sh | 11 +-- 1 file c

[PATCH v6 7/7] ref-filter.c: parse trailers arguments with %(contents) atom

g 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 <m...@ttaylorr.com> --- ref-filter.c| 7 --- t/t6300-for-each-ref.sh | 37

[PATCH v6 4/7] doc: use modern "`"-style code quoting

e quoting instead. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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/Docu

[PATCH v6 1/7] pretty.c: delimit "%(trailers)" arguments with ","

uot;%(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)&

[PATCH v6 3/7] doc: 'trailers' is the preferred way to format trailers

information. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- 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 --- a/Documentati

[PATCH v6 2/7] t4205: unfold across multiple lines

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 <m...@ttaylorr.com> --- t/t4205-log-pretty-form

[PATCH] ref-filter.c: pass empty-string as NULL to atom parsers

ing the 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 Bl

Re: [PATCH v6 7/7] ref-filter.c: parse trailers arguments with %(contents) atom

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

Re: [PATCH v6 0/7] Support %(trailers) arguments in for-each-ref(1)

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

[PATCH v2] ref-filter.c: pass empty-string as NULL to atom parsers

ing the 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 Bl

Re: [PATCH] ref-filter.c: pass empty-string as NULL to atom parsers

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 >

Re: What's cooking in git.git (Oct 2017, #01; Wed, 4)

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

Re: [PATCH] docs/pretty-formats: mention commas in %(trailers) syntax

On Fri, Dec 08, 2017 at 12:16:36AM -0500, Jeff King wrote: > Commit 84ff053d47 (pretty.c: delimit "%(trailers)" arguments > with ",", 2017-10-01) switched the syntax of the trailers > placeholder, but forgot to update the documentation in > pretty-formats.txt. > > There's need to mention the old

[PATCH v4 4/7] grep.c: display column number of first match

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 <m...@ttaylorr.com> --- grep.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/gr

[PATCH v4 1/7] Documentation/config.txt: camel-case lineNumber for consistency

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 &l

[PATCH v4 0/7] Teach '--column' to 'git-grep(1)'

in advance for your review. I am going to send out my next patch (which Ævar suggested) to add '--only-matching' to 'git-grep(1)'. Thanks, Taylor [1]: https://public-inbox.org/git/874lk2e4he@evledraar.gmail.com Taylor Blau (7): Documentation/config.txt: camel-case lineNumber for consistency

[PATCH v4 2/7] grep.c: expose matched column in match_line()

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 Blau <m...@ttaylorr.com> --- g

[PATCH v4 3/7] grep.[ch]: extend grep_opt to allow showing matched column

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 <m...@ttaylorr.com> --- grep.c | 3 +++ grep.h | 2 ++ 2 files changed, 5 inse

[PATCH v4 7/7] contrib/git-jump/git-jump: jump to match column in addition to line

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 additional cleanup is necessary. Signed-off-by: Taylor Blau &l

[PATCH v4 6/7] grep.c: add configuration variables to show matched option

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 <m...@ttaylorr.com> --- Documentation/config.txt | 5 + Documentation/git-grep.t

[PATCH v4 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

-off-by: Taylor Blau <m...@ttaylorr.com> --- Documentation/git-grep.txt | 5 - builtin/grep.c | 1 + t/t7810-grep.sh| 22 ++ 3 files changed, 27 insertions(+), 1 deletion(-) diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt

[PATCH 1/2] grep.c: extract show_line_header()

. For now, show_line_header() provides no benefit over the change before this patch. The following patch will call conditionally call show_line_header() multiple times per invocation to show_line(), which is the desired benefit of this change. Signed-off-by: Taylor Blau <m...@ttaylorr.com> ---

[PATCH 0/2] builtin/grep.c: teach '-o', '--only-matching'

sbb@evledraar.gmail.com Taylor Blau (2): grep.c: extract show_line_header() builtin/grep.c: teach '-o', '--only-matching' to 'git-grep' Documentation/git-grep.txt | 6 +++- builtin/grep.c | 1 + grep.c | 67 +- grep.h |

[PATCH 2/2] builtin/grep.c: teach '-o', '--only-matching' to 'git-grep'

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-off-by: Taylor Blau <m...@ttaylorr.com> --- Documentation/git-gr

Re: [PATCH v4 7/7] contrib/git-jump/git-jump: jump to match column in addition to line

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 <m...@ttaylorr.com> wrote: > >> Take advantage of 'git-grep(1)''s new option, '--column' in order to >

Re: [PATCH v4 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Sat, May 05, 2018 at 08:15:03AM +0200, Duy Nguyen wrote: > On Sat, May 5, 2018 at 4:43 AM, Taylor Blau <m...@ttaylorr.com> wrote: > > Teach 'git-grep(1)' a new option, '--column', to show the column > > number of the first match on a non-context line. > > Why?

Re: [PATCH v4 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

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 --column-n

[PATCH v5 0/7] Teach '--column' to 'git-grep(1)'

://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-ct.c.googlers.com [6]: https://public-inbox.org/git/87d0y8y84q@evledraar.gmail.com/ Taylo

[PATCH v5 6/7] grep.c: add configuration variables to show matched option

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 <m...@ttaylorr.com> --- Documentation/config.txt | 5 + Documentation/git-grep.t

[PATCH v5 3/7] grep.[ch]: extend grep_opt to allow showing matched column

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 <m...@ttaylorr.com> --- grep.c | 3 +++ grep.h | 2 ++ 2 files changed, 5 inse

[PATCH v5 7/7] contrib/git-jump/git-jump: jump to match column in addition to line

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 additional cleanup is necessary. Signed-off-by: Taylor Blau &l

[PATCH v5 4/7] grep.c: display column number of first match

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 <m...@ttaylorr.com> --- grep.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/gr

[PATCH v5 1/7] Documentation/config.txt: camel-case lineNumber for consistency

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 &l

[PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

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 <m...@ttaylorr.com> --- Documentation/git-grep.txt | 6 +- builtin/

Re: [PATCH v4 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Mon, May 07, 2018 at 11:13:12PM +0900, Junio C Hamano wrote: > Taylor Blau <m...@ttaylorr.com> writes: > > > diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt > > index 18b494731f..5409a24399 100644 > > --- a/Documentation/git-grep.txt > &

Re: [PATCH 2/2] builtin/grep.c: teach '-o', '--only-matching' to 'git-grep'

On Sat, May 05, 2018 at 03:36:12AM -0400, Eric Sunshine wrote: > On Sat, May 5, 2018 at 12:03 AM, Taylor Blau <m...@ttaylorr.com> wrote: > > Teach GNU grep(1)'s '-o' ('--only-matching') to 'git-grep'. This option > > prints only the matching components of each line. It writ

Re: [GSoC] A blog about 'git stash' project

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

Re: [PATCH 1/2] grep.c: extract show_line_header()

On Sat, May 05, 2018 at 03:30:51AM -0400, Eric Sunshine wrote: > On Sat, May 5, 2018 at 12:03 AM, Taylor Blau <m...@ttaylorr.com> wrote: > > Teach 'git-grep(1)' how to print a line header multiple times from > > show_line() in preparation for it learning '--only-matching'. >

[PATCH v5 2/7] grep.c: expose matched column in match_line()

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 Blau <m...@ttaylorr.com> --- g

Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Wed, May 09, 2018 at 07:26:57PM +0200, Martin Ågren wrote: > On 9 May 2018 at 12:41, Phillip Wood <phillip.w...@talktalk.net> wrote: > > On 09/05/18 03:13, Taylor Blau wrote: > >> > >> +--column:: > >> + Prefix the 1-indexed byte-offset of

Re: [PATCH 2/2] builtin/grep.c: teach '-o', '--only-matching' to 'git-grep'

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 && > > >

Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

On Wed, May 09, 2018 at 06:17:20PM +0200, Duy Nguyen wrote: > On Wed, May 9, 2018 at 4:13 AM, Taylor Blau <m...@ttaylorr.com> wrote: > > diff --git a/builtin/grep.c b/builtin/grep.c > > index 5f32d2ce84..f9f516dfc4 100644 > > --- a/builtin/grep.c > > +++ b/bu

Re: [PATCH v5 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

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 possible > > to

[PATCH v2 1/2] grep.c: extract show_line_header()

, 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 Blau <m...@ttaylorr.com> --- grep.

[PATCH v2 2/2] builtin/grep.c: teach '-o', '--only-matching' to 'git-grep'

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 are meaningless. Signed-off-by: Taylor Blau <m...@ttaylorr.com> --- Documen

[PATCH v2 0/2] builtin/grep.c: teach '-o', '--only-matching'

/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 Taylor Blau (2): grep.c: extract

[PATCH v6 4/7] grep.c: display column number of first match

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 <m...@ttaylorr.com> --- grep.c | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/gr

[PATCH v6 5/7] builtin/grep.c: add '--column' option to 'git-grep(1)'

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 <m...@ttaylorr.com> --- Documentation/git-grep.txt | 7 ++- builtin/

[PATCH v6 7/7] contrib/git-jump/git-jump: jump to match column in addition to line

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 additional cleanup is necessary. Signed-off-by: Taylor Blau &l

[PATCH v6 6/7] grep.c: add configuration variables to show matched option

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 <m...@ttaylorr.com> --- Documentation/config.txt | 5 + Documentation/git-grep.t

[PATCH v6 0/7] Teach '--column' to 'git-grep(1)'

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 lineNumber for consistency grep.c: expo

[PATCH v6 2/7] grep.c: expose matched column in match_line()

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 Blau <m...@ttaylorr.com> --- g

  1   2   3   4   >