Re: [PATCHv5 00/17] Diff machine: highlight moved lines.

I was trying to see how this is useful in code moving change, with this command line: $ git -c color.moved diff js/blame-lib~6 js/blame-lib blame.c blame.h builtin/blame.c Some random observations: * You do not seem to have any command line option yet. I guess that is OK while the series

Re: [PATCH v2 7/7] grep: add support for PCRE v2

On Wed, May 24, 2017 at 8:23 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Add support for v2 of the PCRE API. This is a new major version of >> PCRE that came out in early 2015[1]. >> >> The regular expression syntax is the same, but

Re: [PATCH v2 1/7] grep: don't redundantly compile throwaway patterns under threading

On Wed, May 24, 2017 at 6:42 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Rather, it's just to make the code easier to reason about. It's >> confusing to debug this under threading & non-threading when the >> threading codepaths

Re: [PATCH v2 0/2] Update sha1dc from upstream & optionally make it a submodule

On Tue, May 23, 2017 at 3:06 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Seems like it would be useful to have a way to ex-post-facto say "past >> history should use these URLs". i.e. if all git.git mirrors go down >> and we have to

Documentation issue: git-stash examples

Some of the example commands in git-stash documentation should be written as comments rather than actual commands: https://cloud.githubusercontent.com/assets/24915363/26444394/5cf6a754-4190-11e7-845e-135288c8916e.png For example, `$ edit emergency fix` should be `# ... edit emergency fix ...`

[PATCH v3 2/2] Windows: do not treat a path with backslashes as a remote's nick name

On Windows, the remote repository name in, e.g., `git fetch foo\bar` is clearly not a nickname for a configured remote repository. However, the function valid_remote_nick() does not account for backslashes. Use is_dir_sep() to check for both slashes and backslashes on Windows. This was discovered

Re: [PATCH 2/3] sha1dc: use sha1collisiondetection as a submodule

On Sat, May 20, 2017 at 1:13 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Replace the forked sha1dc directory with a copy of the upstream code >> imported as a submodule. This is the exact same code as now exists in >> the sha1dc/

Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch

Jeff King writes: > I dunno. I was thinking there might be a quick tweak, but I'm wondering > if this arcane case is worth the restructuring we'd have to do to > support it. It only comes up when you've moved the server repo's HEAD to > an unborn branch _and_ you have other refs

Re: `pull --rebase --autostash` fails when fast forward in dirty repo

Jeff King writes: > Anyway. All this has shown me is that it's probably pointless to do this > timing at all on Linux. Somebody on Windows might get better results. > > But regardless, we need to do something. Correctness must trump > optimizations, and the question is whether we

Re: [RFC/PATCH] recognize pathspec magic without "--" disambiguation

Jeff King writes: > But let's consider related invocations and whether we're > making them better or worse: > >- git log :/foo > (when "foo" matches a commit message) > > This one should remain the same. Like the existing > wildcard rule, we're touching only

[PATCH v4 03/10] rebase -i: remove useless indentation

Hi Johannes, Johannes Schindelin writes: > The commands used to be indented, and it is nice to look at, but when we > transform the SHA-1s, the indentation is removed. So let's do away with it. > > For the moment, at least: when we will use the upcoming

[PATCH v4 05/10] rebase -i: also expand/collapse the SHA-1s via the rebase--helper

Hi Johannes, Johannes Schindelin writes: > This is crucial to improve performance on Windows, as the speed is now > mostly dominated by the SHA-1 transformation (because it spawns a new > rev-parse process for *every* line, and spawning processes is pretty > slow from

[PATCH v4 02/10] rebase -i: generate the script via rebase--helper

Hi Johannes, Johannes Schindelin writes: > The first step of an interactive rebase is to generate the so-called "todo > script", to be stored in the state directory as "git-rebase-todo" and to > be edited by the user. > > Originally, we adjusted the output of `git

[PATCH v4 10/10] rebase -i: rearrange fixup/squash lines using the rebase--helper

Hi Johannes, Johannes Schindelin writes: > This operation has quadratic complexity, which is especially painful > on Windows, where shell scripts are *already* slow (mainly due to the > overhead of the POSIX emulation layer). > > Let's reimplement this with linear

Feature request: "git status" highlights files that are larger than 500kb.

So it will be easy to track that we don't accidentally commit huge files. What do you think?

Re: [PATCH v2 0/2] Update sha1dc from upstream & optionally make it a submodule

Ævar Arnfjörð Bjarmason writes: > But from what you're saying here that seems like a non-issue, i.e. in > such a scenario we'd just mirror the original repo[1], change the URL > in git.git to that, and then anyone could easily use older history > since it would be pointing to

Re: [PATCHv5 00/17] Diff machine: highlight moved lines.

Stefan Beller writes: > As you turn on/off normal coloring via "color.diff" and this only extends > the coloring scheme, I have the impression "color" is the right section. > Maybe color.diffStyle=[normal/enhanced] and "enhanced" means this > feature for now? Hmph, I thought

Re: What's cooking in git.git (May 2017, #06; Mon, 22)

Duy Nguyen writes: > On Mon, May 22, 2017 at 1:11 PM, Junio C Hamano wrote: >> * nd/fopen-errors (2017-05-09) 23 commits >> - t1308: add a test case on open a config directory >> - config.c: handle error on failing to fopen() >> - xdiff-interface.c:

[PATCH v4 00/10] The final building block for a faster rebase -i

Hi Johannes, Johannes Schindelin writes: > This patch series reimplements the expensive pre- and post-processing of > the todo script in C. > > And it concludes the work I did to accelerate rebase -i. > > Changes since v3: > > - removed the no-longer-used

Re: [PATCH v2 1/7] grep: don't redundantly compile throwaway patterns under threading

Ævar Arnfjörð Bjarmason writes: > I think it's a pointless distraction to start speculating in this > commit message what we're going to do with --debug it if it ever > starts emitting some debugging information at pattern execution time. OK. > As an aside, I'd very much like

Re: [PATCH v6 6/6] clean: teach clean -d to preserve ignored paths

Samuel Lijin writes: > On Wed, May 24, 2017 at 12:14 AM, Torsten Bögershausen wrote: >> >>> diff --git a/builtin/clean.c b/builtin/clean.c >>> index d861f836a..937eb17b6 100644 >>> --- a/builtin/clean.c >>> +++ b/builtin/clean.c >>> @@ -857,6 +857,38 @@ static

Re: [PATCHv5 16/17] diff: buffer all output if asked to

Stefan Beller writes: > Yes, this is essentially the v4 with small indentation fixes, so I > assumed your signoff is still valid. OK. I just didn't expect to see one without "no changes since v4" under the three-dash line. Thanks.

Re: Documentation issue: git-stash examples

On Fri, May 26, 2017 at 08:37:41AM +1200, Adrian Forbes wrote: > Yep, but how do I send it back to you? As a mail attachment? Usually you'd send it to the list, with the commit message in the body and the patch inline below, as generated by "git format-patch". Unfortunately gmail is notorious

Re: [PATCH v2 6/6] fsmonitor: add a sample query-fsmonitor hook script for Watchman

On Thu, May 18, 2017 at 10:13 PM, Ben Peart wrote: > This hook script integrates the new fsmonitor capabilities of git with > the cross platform Watchman file watching service. To use the script: > > Download and install Watchman from https://facebook.github.io/watchman/ > and

Re: [PATCH v3 2/2] Windows: do not treat a path with backslashes as a remote's nick name

Johannes Sixt writes: >>> So in short: >>> >>> (1) Hannes's patches are good, but they solve a problem that is >>> different from what their log messages say; the log message >>> needs to be updated; > > I do not resend patch 1/2 as it is unchanged in all regards.

[PATCH] docs/config.txt: fix indefinite article in core.fileMode description

Signed-off-by: SZEDER Gábor --- Documentation/config.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 475e874d5..f9adc9afa 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt

Re: `pull --rebase --autostash` fails when fast forward in dirty repo

On Wed, May 24, 2017 at 07:40:08AM +0900, Junio C Hamano wrote: > > But I notice on the run_merge() code path that we do still invoke > > git-merge. > > ... wouldn't that what we want even when the merge happens to be a > fast-forward one? I am not sure what you meant by this, but... I just

Re: `pull --rebase --autostash` fails when fast forward in dirty repo

On Thu, May 25, 2017 at 02:04:07PM -0400, Jeff King wrote: > > ...that might be something worth thinking about---my gut feeling > > tells me something but we should go by a measurement, not by gut > > feeling of a random somebody. > > Yeah, I'd agree. I had the impression the original change was

[RFC/PATCH] recognize pathspec magic without "--" disambiguation

For commands that take revisions and pathspecs, magic pathspecs like ":^Documentation" or ":/Documentation" have to appear on the right-hand side of the disambiguating "--", like: git log -- :^Documentation This makes them more annoying to use than they need to be. We loosened the rules for

Re: [PATCH v6 6/6] clean: teach clean -d to preserve ignored paths

On Wed, May 24, 2017 at 12:14 AM, Torsten Bögershausen wrote: > >> diff --git a/builtin/clean.c b/builtin/clean.c >> index d861f836a..937eb17b6 100644 >> --- a/builtin/clean.c >> +++ b/builtin/clean.c >> @@ -857,6 +857,38 @@ static void interactive_main_loop(void) >> } >>

Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch

On Thu, May 25, 2017 at 12:13:03PM +0900, Junio C Hamano wrote: > >> So if we wanted to improve this, I think the first step would be for the > >> server to start sending symref lines for HEAD, even when it does not > >> resolve to anything. > > > > Yup, noticed the same and I agree with your

Re: [PATCH 28/29] blame: move scoreboard setup to libgit

I had meant to change the name to match what is in find_single_final. While the intent was for it to change while in builtin/blame.c, apparently I missed that in the shuffle. On Thu, May 25, 2017 at 12:53 AM, Junio C Hamano wrote: > Jeff Smith writes: > >>

Re: [PATCH v2 0/6] Fast git status via a file system watcher

On 5/24/2017 6:54 AM, Christian Couder wrote: Design ~~ A new git hook (query-fsmonitor) must exist and be enabled (core.fsmonitor=true) that takes a time_t formatted as a string and outputs to stdout all files that have been modified since the requested time. Is there a reason why

Re: [PATCH v2 1/2] refs: Add for_each_worktree_ref for iterating over all worktree HEADs

On Tue, May 23, 2017 at 5:52 AM, Manish Goregaokar wrote: > What work is remaining for prune-in-worktree? Link to the relevant > discussions? > > I might be able to take it over the finish line. (No guarantees) The finish line should be pretty close. I've addressed

Re: What's cooking in git.git (May 2017, #06; Mon, 22)

On Mon, May 22, 2017 at 1:11 PM, Junio C Hamano wrote: > * nd/fopen-errors (2017-05-09) 23 commits > - t1308: add a test case on open a config directory > - config.c: handle error on failing to fopen() > - xdiff-interface.c: report errno on failure to stat() or fopen() > -

Re: [PATCH v2 5/6] fsmonitor: add documentation for the fsmonitor extension.

On 5/22/2017 1:28 PM, Ævar Arnfjörð Bjarmason wrote: On Mon, May 22, 2017 at 6:18 PM, Ben Peart wrote: On 5/20/2017 8:10 AM, Ævar Arnfjörð Bjarmason wrote: +== File System Monitor cache + + The file system monitor cache tracks files for which the query-fsmonitor +

[PATCH v3 03/13] clone: use xfopen() instead of fopen()

From: Nguyễn Thái Ngọc Duy copy_alternates() called fopen() without handling errors. By switching to xfopen(), this bug is fixed. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- builtin/clone.c | 2 +- 1 file

[PATCH v3 05/13] config.mak.uname: set FREAD_READS_DIRECTORIES for Darwin, too

Signed-off-by: Junio C Hamano --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index a25ffddb3e..1743890164 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -110,6 +110,7 @@ ifeq ($(uname_S),Darwin)

[PATCH v3 00/13] reporting unexpected errors after (f)open

These are taken from https://github.com/pclouds/git/commits/fopen-or-warn cf.

[PATCH v3 06/13] wrapper.c: add and use warn_on_fopen_errors()

From: Nguyễn Thái Ngọc Duy In many places, Git warns about an inaccessible file after a fopen() failed. To discern these cases from other cases where we want to warn about inaccessible files, introduce a new helper specifically to test whether fopen() failed because the

[PATCH v3 02/13] use xfopen() in more places

From: Nguyễn Thái Ngọc Duy xfopen() - provides error details - explains error on reading, or writing, or whatever operation - has l10n support - prints file name in the error Some of these are missing in the places that are replaced with xfopen(), which is a clear win.

[PATCH v3 04/13] config.mak.uname: set FREAD_READS_DIRECTORIES for Linux and FreeBSD

From: Nguyễn Thái Ngọc Duy This variable is added [1] with the assumption that on a sane system, fopen(, "r") should return NULL. Linux and FreeBSD do not meet this expectation while at least Windows and AIX do. Let's make sure they behave the same way. I only tested one

[PATCH v3 01/13] git_fopen: fix a sparse 'not declared' warning

From: Ramsay Jones If git is built with the FREAD_READS_DIRECTORIES build variable set, this would cause sparse to issue a 'not declared, should it be static?' warning on Linux. This is a result of the method employed by 'compat/fopen.c' to suppress the (possible)

[PATCH v3 07/13] wrapper.c: add and use fopen_or_warn()

From: Nguyễn Thái Ngọc Duy When fopen() returns NULL, it could be because the given path does not exist, but it could also be some other errors and the caller has to check. Add a wrapper so we don't have to repeat the same error check everywhere. Signed-off-by: Nguyễn Thái

[PATCH v3 09/13] print errno when reporting a system call error

From: Nguyễn Thái Ngọc Duy Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- builtin/log.c | 3 ++- rerere.c | 4 ++-- xdiff-interface.c | 4 ++-- 3 files changed, 6 insertions(+), 5 deletions(-) diff

[PATCH v3 11/13] log: fix memory leak in open_next_file()

From: Nguyễn Thái Ngọc Duy Noticed-by: Jeff King Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano --- builtin/log.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git

[PATCH v3 10/13] rerere.c: move error_errno() closer to the source system call

From: Nguyễn Thái Ngọc Duy We are supposed to report errno from fopen(). fclose() between fopen() and the report function could either change errno or reset it. Signed-off-by: Junio C Hamano --- rerere.c | 3 ++- 1 file changed, 2 insertions(+), 1

[PATCH v3 08/13] wrapper.c: make warn_on_inaccessible() static

From: Nguyễn Thái Ngọc Duy After the last patch, this function is not used outside anymore. Keep it static. Noticed-by: Ramsay Jones Signed-off-by: Junio C Hamano --- git-compat-util.h | 2 -- wrapper.c | 10

[PATCH v3 12/13] wrapper: factor out is_missing_file_error()

Our code often opens a path to an optional file, to work on its contents when we can successfully open it. We can ignore a failure to open if such an optional file does not exist, but we do want to report a failure in opening for other reasons (e.g. we got an I/O error, or the file is there, but

[PATCH v3 13/13] is_missing_file_error(): work around EINVAL on Windows

When asked to open/fopen a path, e.g. "a/b:/c", which does not exist on the filesystem, Windows (correctly) fails to open it but sets EINVAL to errno because the pathname has characters that cannot be stored in its filesystem. As this is an expected failure, teach is_missing_file_error() helper

Bug report: Corrupt pack file after committing a large file (>4 GB?)

Dear maintainer, There is a bug where committing a large file corrupts the pack file in Windows. Steps to recreate are: 1. git init 2. stage and commit a file larger than 4 GB (not entirely sure about this size) 3. git checkout -f The file checked out is much smaller than the original file

Re: `pull --rebase --autostash` fails when fast forward in dirty repo

Tyler Brazier writes: > On Thu, May 25, 2017 at 6:33 PM, Junio C Hamano wrote: >> Jeff King writes: >> >>> Anyway. All this has shown me is that it's probably pointless to do this >>> timing at all on Linux. Somebody on Windows might

Re: [PATCH] docs/config.txt: fix indefinite article in core.fileMode description

Obviously correct. Thanks.

Re: `pull --rebase --autostash` fails when fast forward in dirty repo

Does git accept outside pull requests? I wouldn't mind committing the fix for this once it's been decided what the fix should be. (It might help my resume ;) On Thu, May 25, 2017 at 6:33 PM, Junio C Hamano wrote: > Jeff King writes: > >> Anyway. All this has

Urgent Message

Dear Good day, I sent this mail praying for it to reach you in good health, since I myself are in a very critical health condition in which I sleep every night without knowing if I may be alive to see the next day. I am a widow suffering from long time illness. I have some funds I inherited from

Re: [PATCHv5 00/17] Diff machine: highlight moved lines.

On Wed, May 24, 2017 at 11:44 PM, Junio C Hamano wrote: > I was trying to see how this is useful in code moving change, with > this command line: > > $ git -c color.moved diff js/blame-lib~6 js/blame-lib blame.c blame.h > builtin/blame.c > > Some random observations: > > *

[PATCH v3 6/6] fsmonitor: add a sample query-fsmonitor hook script for Watchman

This hook script integrates the new fsmonitor capabilities of git with the cross platform Watchman file watching service. To use the script: Download and install Watchman from https://facebook.github.io/watchman/ and instruct Watchman to watch your working directory for changes ('watchman

[PATCH v3 3/6] fsmonitor: teach git to optionally utilize a file system monitor to speed up detecting new or changed files.

When the index is read from disk, the query-fsmonitor index extension is used to flag the last known potentially dirty index and untracked cache entries. If git finds out some entries are 'fsmonitor-dirty', but are really unchanged (e.g. the file was changed, then reverted back), then Git will

[PATCH v3 5/6] fsmonitor: add documentation for the fsmonitor extension.

This includes the core.fsmonitor setting, the query-fsmonitor hook, and the fsmonitor index extension. Signed-off-by: Ben Peart --- Documentation/config.txt | 7 +++ Documentation/githooks.txt | 23 +++

[PATCH v3 0/6] Fast git status via a file system watcher

Changes from V2 include: - switch to nanoseconds for last update time saved in index extension and passed to hook - pass the hook a version to enable simpler future updates - fixup compiler warnings found with different compilers - update test to run properly on Mac - fix documentation

[PATCH v3 4/6] fsmonitor: add test cases for fsmonitor extension

Add test cases that ensure status results are correct when using the new fsmonitor extension. Test untracked, modified, and new files by ensuring the results are identical to when not using the extension. Add a test to ensure updates to the index properly mark corresponding entries in the index

[PATCH v3 1/6] bswap: add 64 bit endianness helper get_be64

Add a new get_be64 macro to enable 64 bit endian conversions on memory that may or may not be aligned. Signed-off-by: Ben Peart --- compat/bswap.h | 4 1 file changed, 4 insertions(+) diff --git a/compat/bswap.h b/compat/bswap.h index d47c003544..f89fe7f4b5 100644

[PATCH v3 2/6] dir: make lookup_untracked() available outside of dir.c

Remove the static qualifier from lookup_untracked() and make it available to other modules by exporting it from dir.h. This will be used later when we need to find entries to mark 'fsmonitor dirty.' Signed-off-by: Ben Peart --- dir.c | 2 +- dir.h | 3 +++ 2 files

Re: Documentation issue: git-stash examples

On Thu, May 25, 2017 at 09:52:42PM +1200, Adrian Forbes wrote: > Some of the example commands in git-stash documentation should be > written as comments rather than actual commands: > https://cloud.githubusercontent.com/assets/24915363/26444394/5cf6a754-4190-11e7-845e-135288c8916e.png > > For

`git svn branch` does not respect authors file

I have a git repository linked to a svn repository with git-svn, including a branch path configuration and an authorsfile for svn username -> email mapping. When running `git svn branch new_branch`, git-svn: * Creates a svn commit creating a new svn branch * Creates a local git commit linked to

Re: [Non-Bug] cloning a repository with a default MASTER branch tries to check out the master branch

On Thu, May 25, 2017 at 11:59:24AM -0400, Jeff King wrote: > The just-HEAD case could look like: This patch does work, in the sense that upload-pack advertises the unborn HEAD symref. But the client doesn't actually do anything with it. The capability parsing happens in get_remote_heads(), which

[PATCH] connect.c: fix leak in parse_one_symref_info()

If we successfully parse a symref value like "HEAD:refs/heads/master", we add the result to a string list. But because the string list is marked STRING_LIST_INIT_DUP, the string list code will make a copy of the string and add the copy. This patch fixes it by adding the entry with

[PATCH v4 03/31] test-lib: rename the LIBPCRE prerequisite to PCRE

Rename the LIBPCRE prerequisite to PCRE. This is for preparation for libpcre2 support, where having just "LIBPCRE" would be confusing as it implies v1 of the library. None of these tests are incompatible between versions 1 & 2 of libpcre, it's less confusing to give them a more general name to

[PATCH v4 01/31] Makefile & configure: reword inaccurate comment about PCRE

Reword an outdated & inaccurate comment which suggests that only git-grep can use PCRE. This comment was added back when PCRE support was initially added in commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09), and was true at the time. It hasn't been telling the full truth since git-log

[PATCH v4 02/31] grep & rev-list doc: stop promising libpcre for --perl-regexp

Stop promising in our grep & rev-list options documentation that we're always going to be using libpcre when given the --perl-regexp option. Instead talk about using "Perl-compatible regular expressions" and using these types of patterns using "a compile-time dependency". Saying "libpcre" means

[PATCH v4 06/31] grep: add a test asserting that --perl-regexp dies when !PCRE

Add a test asserting that when --perl-regexp (and -P for grep) is given to git-grep & git-log that we die with an error. In developing the PCRE v2 series I introduced a regression where -P would (through control-flow fall-through) become synonymous with basic POSIX matching. I.e. 'git grep -P

[PATCH v4 09/31] grep: add tests for --threads=N and grep.threads

Add tests for --threads=N being supplied on the command-line, or when grep.threads=N being supplied in the configuration. When the threading support was made run-time configurable in commit 89f09dd34e ("grep: add --threads= option and grep.threads configuration", 2015-12-15) no tests were added

[PATCH v4 11/31] grep: add tests for grep pattern types being passed to submodules

Add testing for grep pattern types being correctly passed to submodules. The pattern "(.|.)[\d]" matches differently under fixed (not at all), and then matches different lines under basic/extended & perl regular expressions, so this change asserts that the pattern type is passed along correctly.

[PATCH v4 08/31] grep: change non-ASCII -i test to stop using --debug

Change a non-ASCII case-insensitive test case to stop using --debug, and instead simply test for the expected results. The test coverage remains the same with this change, but the test won't break due to internal refactoring. This test was added in commit 793dc676e0 ("grep/icase: avoid kwsset

[PATCH v4 05/31] log: make --regexp-ignore-case work with --perl-regexp

Make the --regexp-ignore-case option work with --perl-regexp. This never worked, and there was no test for this. Fix the bug and add a test. When PCRE support was added in commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) compile_pcre_regexp() would only check opt->ignore_case, but when the

[PATCH v4 10/31] grep: amend submodule recursion test for regex engine testing

Amend the submodule recursion test to prepare it for subsequent tests of whether it passes along the grep.patternType to the submodule greps. This is the result of searching & replacing: foobar -> (1|2)d(3|4) foo-> (1|2) bar-> (3|4) Currently there's no tests for whether

[PATCH v4 04/31] log: add exhaustive tests for pattern style options & config

Add exhaustive tests for how the different grep.patternType options & the corresponding command-line options affect git-log. Before this change it was possible to patch revision.c so that the --basic-regexp option was synonymous with --extended-regexp, and --perl-regexp wasn't recognized at all,

[PATCH v4 00/31] Easy to review grep & pre-PCRE changes

Easy to review? 29 (I mean 30, I mean 31) patches? Are you kidding me?! As noted in v1 (<20170511091829.5634-1-ava...@gmail.com>; https://public-inbox.org/git/20170511091829.5634-1-ava...@gmail.com/) these are all doc, test, refactoring etc. changes needed by the subsequent "PCRE v2, PCRE v1 JIT,

[PATCH v4 18/31] perf: add a comparison test of grep regex engines with -F

Add a performance comparison test of grep regex engines given fixed strings. The current logic in compile_regexp() ignores the engine parameter and uses kwset() to search for these, so this test shows no difference between engines right now: $ GIT_PERF_REPEAT_COUNT=10

[PATCH v4 24/31] grep: change the internal PCRE macro names to be PCRE1

Change the internal USE_LIBPCRE define, & build options flag to use a naming convention ending in PCRE1, without changing the long-standing USE_LIBPCRE Makefile flag which enables this code. This is for preparation for libpcre2 support where having things like USE_LIBPCRE and USE_LIBPCRE2 in any

[PATCH v4 28/31] pack-objects & index-pack: add test for --threads warning

Add a test for the warning that's emitted when --threads or pack.threads is provided under NO_PTHREADS=YesPlease. This uses the new PTHREADS prerequisite. The assertion for C_LOCALE_OUTPUT in the latter test is currently redundant, since unlike index-pack the pack-objects warnings aren't i18n'd.

[PATCH v4 25/31] grep: change internal *pcre* variable & function names to be *pcre1*

Change the internal PCRE variable & function names to have a "1" suffix. This is for preparation for libpcre2 support, where having non-versioned names would be confusing. An earlier change in this series ("grep: change the internal PCRE macro names to be PCRE1", 2017-04-07) elaborates on the

[PATCH v4 17/31] perf: add a comparison test of grep regex engines

Add a very basic performance comparison test comparing the POSIX basic, extended and perl engines. In theory the "basic" and "extended" engines should be implemented using the same underlying code with a slightly different pattern parser, but some implementations may not do this. Jump through

[PATCH v4 15/31] perf: add a GIT_PERF_MAKE_COMMAND for when *_MAKE_OPTS won't do

Add a git GIT_PERF_MAKE_COMMAND variable to compliment the existing GIT_PERF_MAKE_OPTS facility. This allows specifying an arbitrary shell command to execute instead of 'make'. This is useful e.g. in cases where the name, semantics or defaults of a Makefile flag have changed over time. It can

[PATCH v4 16/31] perf: emit progress output when unpacking & building

Amend the t/perf/run output so that in addition to the "Running N tests" heading currently being emitted, it also emits "Unpacking $rev" and "Building $rev" when setting up the build/$rev directory & when building it, respectively. This makes it easier to see what's going on and what revision is

[PATCH v4 19/31] perf: add a comparison test of log --grep regex engines

Add a very basic performance comparison test comparing the POSIX basic, extended and perl engines with patterns matching log messages via --grep=. $ GIT_PERF_REPEAT_COUNT=10 GIT_PERF_LARGE_REPO=~/g/linux ./run p4220-log-grep-engines.sh [...] Test

[PATCH v4 20/31] perf: add a comparison test of log --grep regex engines with -F

Add a performance comparison test of log --grepgrep regex engines given fixed strings. See the preceding fixed-string t/perf change ("perf: add a comparison test of grep regex engines with -F", 2017-04-21) for notes about this, in particular this mostly tests exactly the same codepath now, but

[PATCH v4 12/31] grep: add a test helper function for less verbose -f \0 tests

Add a helper function to make the tests which check for patterns with \0 in them more succinct. Right now this isn't a big win, but subsequent commits will add a lot more of these tests. The helper is based on the match() function in t3070-wildmatch.sh. Signed-off-by: Ævar Arnfjörð Bjarmason

[PATCH v4 13/31] grep: prepare for testing binary regexes containing rx metacharacters

Add setup code needed for testing regexes that contain both binary data and regex metacharacters. The POSIX regcomp() function inherently can't support that, because it takes a \0-delimited char *, but other regex engines APIs like PCRE v2 take a pattern/length pair, and are thus able to handle

[PATCH v4 07/31] grep: add a test for backreferences in PCRE patterns

Add a test for backreferences such as (.)\1 in PCRE patterns. This test ensures that the PCRE_NO_AUTO_CAPTURE option isn't turned on. Before this change turning it on would break these sort of patterns, but wouldn't break any tests. Signed-off-by: Ævar Arnfjörð Bjarmason ---

[PATCH v4 23/31] grep: factor test for \0 in grep patterns into a function

Factor the test for \0 in grep patterns into a function. Since commit 9eceddeec6 ("Use kwset in grep", 2011-08-21) any pattern containing a \0 is considered fixed as regcomp() can't handle it. This change makes later changes that make use of either has_null() or is_fixed() (but not both) smaller.

[PATCH v4 21/31] grep: catch a missing enum in switch statement

Add a die(...) to a default case for the switch statement selecting between grep pattern types under --recurse-submodules. Normally this would be caught by -Wswitch, but the grep_pattern_type type is converted to int by going through parse_options(). Changing the argument type passed to

[PATCH v4 22/31] grep: remove redundant regflags assignments

Remove redundant assignments to the "regflags" variable. This variable is only used set under GREP_PATTERN_TYPE_ERE, so there's no need to un-set it under GREP_PATTERN_TYPE_{FIXED,BRE,PCRE}. Back in 5010cb5fcc[1], we did do "opt.regflags &= ~REG_EXTENDED" upon seeing "-G" on the command line and

[PATCH v4 30/31] grep: given --threads with NO_PTHREADS=YesPlease, warn

Add a warning about missing thread support when grep.threads or --threads is set to a non 0 (default) or 1 (no parallelism) value under NO_PTHREADS=YesPlease. This is for consistency with the index-pack & pack-objects commands, which also take a --threads option & are configurable via

[PATCH v4 27/31] test-lib: add a PTHREADS prerequisite

Add a PTHREADS prerequisite which is false when git is compiled with NO_PTHREADS=YesPlease. There's lots of custom code that runs when threading isn't available, but before this prerequisite there was no way to test it. Signed-off-by: Ævar Arnfjörð Bjarmason --- Makefile

[PATCH v4 31/31] grep: assert that threading is enabled when calling grep_{lock,unlock}

Change the grep_{lock,unlock} functions to assert that num_threads is true, instead of only locking & unlocking the pthread mutex lock when it is. These functions are never called when num_threads isn't true, this logic has gone through multiple iterations since the initial introduction of grep

[PATCH v4 26/31] grep: move is_fixed() earlier to avoid forward declaration

Move the is_fixed() function which are currently only used in compile_regexp() earlier so it can be used in the PCRE family of functions in a later change. Signed-off-by: Ævar Arnfjörð Bjarmason --- grep.c | 24 1 file changed, 12 insertions(+), 12

[PATCH v4 29/31] pack-objects: fix buggy warning about threads

Fix a buggy warning about threads under NO_PTHREADS=YesPlease. Due to re-using the delta_search_threads variable for both the state of the "pack.threads" config & the --threads option, setting "pack.threads" but not supplying --threads would trigger the warning for both "pack.threads" & --threads.

[PATCH v3 1/7] grep: don't redundantly compile throwaway patterns under threading

Change the pattern compilation logic under threading so that grep doesn't compile a pattern it never ends up using on the non-threaded code path, only to compile it again N times for N threads which will each use their own copy, ignoring the initially compiled pattern. This redundant compilation

[PATCH v3 2/7] grep: skip pthreads overhead when using one thread

Skip the administrative overhead of using pthreads when only using one thread. Instead take the non-threaded path which would be taken under NO_PTHREADS. The threading support was initially added in commit 5b594f457a ("Threaded grep", 2010-01-25) with a hardcoded compile-time number of 8 threads.

  1   2   >