Re: [PATCH 2/3] grep: stop "using" a custom JIT stack with PCRE v2

On Wed, Jul 24, 2019 at 1:20 PM Ævar Arnfjörð Bjarmason wrote: > On Wed, Jul 24 2019, Junio C Hamano wrote: > > > > Does everybody use pcre2 with JIT with Git these days, or only those > > who want to live near the bleeding edge? > > My informal survey of various package recipies suggests that all

[PATCH v2 4/5] repo-settings: create feature.manyFiles setting

From: Derrick Stolee The feature.manyFiles setting is suitable for repos with many files in the working directory. By setting index.version=4 and core.untrackedCache=true, commands such as 'git status' should improve. While adding this setting, modify the index version precedence tests to check

[PATCH v2 0/5] Create 'feature.*' config area and some centralized config parsing

This is a brand-new thread to replace ds/early-access. The discussion on that thread was very helpful [1]. With this in mind, I propose instead a set of "feature.*" config settings that form groups of "community recommended" settings (with some caveats). In the space below, I'll list a set of poss

[PATCH v2 2/5] repo-settings: add feature.manyCommits setting

From: Derrick Stolee When a repo has many commits, it is helpful to write and read the commit-graph file. Future changes to Git may include new config settings that are beneficial in this scenario. Create the 'feature.manyCommits' config setting that changes the default values of 'core.commitGra

[PATCH v2 1/5] repo-settings: consolidate some config settings

From: Derrick Stolee There are a few important config settings that are not loaded during git_default_config. These are instead loaded on-demand. Centralize these config options to a single scan, and store all of the values in a repo_settings struct. The values for each setting are initialized a

[PATCH v2 3/5] repo-settings: parse core.untrackedCache

From: Derrick Stolee The core.untrackedCache config setting is slightly complicated, so clarify its use and centralize its parsing into the repo settings. The default value is "keep" (returned as -1), which persists the untracked cache if it exists. If the value is set as "false" (returned as 0

[PATCH v2 5/5] repo-settings: create feature.experimental setting

From: Derrick Stolee The 'feature.experimental' setting includes config options that are not committed to become defaults, but could use additional testing. Update the following config settings to take new defaults, and to use the repo_settings struct if not already using them: * 'pack.useSpars

Re: [PATCH 5/5] repo-settings: create feature.experimental setting

On 7/23/2019 11:20 AM, Johannes Schindelin wrote: > Hi Stolee, > > On Mon, 22 Jul 2019, Derrick Stolee via GitGitGadget wrote: >> struct path_hashmap_entry { >> struct hashmap_entry e; >> @@ -1375,10 +1376,14 @@ static int handle_rename_via_dir(struct >> merge_options *opt, >> * there

Re: [PATCH v3] documentation: add tutorial for revision walking

Thanks - I think this is a useful guide to what can be a complicated topic. It looks good overall; I just have some minor comments below. > diff --git a/Documentation/Makefile b/Documentation/Makefile > index 76f2ecfc1b..91e5da67c4 100644 > --- a/Documentation/Makefile > +++ b/Documentation/Makefi

Re: [PATCH v3] documentation: add tutorial for revision walking

On 2019.07.01 13:19, Emily Shaffer wrote: > Existing documentation on revision walks seems to be primarily intended > as a reference for those already familiar with the procedure. This > tutorial attempts to give an entry-level guide to a couple of bare-bones > revision walks so that new Git contri

[PATCH v3 3/3] ci: run trace2 schema validation in the CI suite

Signed-off-by: Josh Steadmon --- ci/run-build-and-tests.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh index cdd2913440..ec38bf379a 100755 --- a/ci/run-build-and-tests.sh +++ b/ci/run-build-and-tests.sh @@ -14,6 +14,8 @@ make ma

[PATCH v3 1/3] trace2: Add a JSON schema for trace2 events

Define a JSON schema[1] that can be used to validate trace2 event objects. This can be used to add regression tests to verify that the event output format does not change unexpectedly. Four versions of the schema are provided: * event_schema.json is more permissive. It verifies that all expected

[PATCH v3 0/3] Add a JSON Schema for trace2 events

This is a proof of concept series that formalizes the structure of trace2 event output using JSON-Schema [1]. It provides a validator (written in Go) that verifies the events in a given trace2 event output file match the schema. I am happy to rewrite this validator in some other language, provided

[PATCH v3 2/3] trace2: add a schema validator for trace2 events

trace_schema_validator can be used to verify that trace2 event output conforms to the expectations set by the API documentation and codified in event_schema.json (or strict_schema.json). This allows us to build a regression test to verify that trace2 output does not change unexpectedly. Signed-off

[no subject]

Hello, i offer loan at low interest rate of 3% and is Very easy to get. LEASE/BG/SBLC/DOA at low rates is also available, Are you interested? contact me via E-mail: stefesbo...@outlook.dk Skype: boris.andrew3 Phone: +17865445764 Office: +13395459628 (c)2019 STEFES BORIS FINANCIAL SERVICE ®.

Re: [RFC PATCH v2 2/3] trace2: add a schema validator for trace2 events

Thanks for the review, replies are inline below. On 2019.07.11 15:35, Jakub Narebski wrote: > Josh Steadmon writes: > > > trace_schema_validator can be used to verify that trace2 event output > > conforms to the expectations set by the API documentation and codified > > in event_schema.json (or

Re: [RFC PATCH v2 1/3] trace2: Add a JSON schema for trace2 events

On 2019.07.10 20:32, Jakub Narebski wrote: > Josh Steadmon writes: > > > Define a JSON schema[1] that can be used to validate trace2 event > > objects. This can be used to add regression tests to verify that the > > event output format does not change unexpectedly. > > > > Two versions of the sch

Re: [PATCH] submodule: plumb --filter to cloned submodules

> When cloning a repo with a --filter and with --recurse-submodules > enabled, the partial clone filter only applies to the top-level repo. > This can lead to unexpected bandwidth and disk usage for projects which > include large submodules. > > Fix this by plumbing the --filter argument from git-

Re: [PATCH] grep: print the pcre2_jit_on value

Hi Dscho, On 23.07.19 21:19, Johannes Schindelin wrote: > Hi Beat, > > On Mon, 22 Jul 2019, Beat Bolli wrote: > >> When pcre2_jit_on is neither 1 nor 0, the BUG() call printed the value >> of pcre1_jit_on. >> >> Print the value of pcre2_jit_on instead. >> >> Signed-off-by: Beat Bolli >> --- >>

[GSoC][PATCH v3 1/1] rebase -i: add --ignore-whitespace flag

There are two backends available for rebasing, viz, the am and the interactive. Naturally, there shall be some features that are implemented in one but not in the other. One such flag is --ignore-whitespace which indicates merge mechanism to treat lines with only whitespace changes as unchanged. Wi

[GSoC][PATCH v3 0/1] rebase -i: add --ignore-whitespace flag

This revision removes --ignore-whitespace from rebase--interactive since its only caller preserve-merges is now deprecated. Also rename t3431 to t3433. Rohit Ashiwal (1): rebase -i: add --ignore-whitespace flag Documentation/git-rebase.txt| 10 +++- builtin/rebase.c

[PATCH 1/2] rebase: fix white-space

From: Johannes Schindelin This trailing space was inadvertently introduced in 9fbcc3d203 (Merge branch 'js/rebase-orig-head-fix', 2019-03-20). Signed-off-by: Johannes Schindelin --- builtin/rebase.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/rebase.c b/builtin/

[PATCH 2/2] git: mark cmd_rebase as requiring a worktree

From: Johannes Schindelin We skipped marking the "rebase" built-in as requiring a .git/ directory and a worktree only to allow to spawn the scripted version of `git rebase`. Now that we no longer have that escape hatch, we can change that to the canonical form. Signed-off-by: Johannes Schindeli

[PATCH 0/2] Clean up more of the fall-out from dropping the scripted git rebase

I had prepared these patches even before v2.22.0, but deemed them not critical enough to push into that release. Johannes Schindelin (2): rebase: fix white-space git: mark cmd_rebase as requiring a worktree builtin/rebase.c | 6 +- git.c| 7 +-- 2 files changed, 2 inserti

Re: [PATCH] grep: skip UTF8 checks explicitally

Ævar Arnfjörð Bjarmason writes: > The PCRE2_NO_UTF_CHECK flag means "I have checked that this is a valid > UTF-8 string so you, PCRE, don't need to re-check it". OK, in short, barfing and stopping is a problem, but that flag is not the right knob to tweak. And the right knob ... > 1) We're ov

Re: [PATCH 3/5] repo-settings: parse core.untrackedCache

On 7/23/2019 11:04 AM, Johannes Schindelin wrote: > Hi Stolee, > > On Mon, 22 Jul 2019, Derrick Stolee via GitGitGadget wrote: > >> From: Derrick Stolee >> >> The core.untrackedCache config setting is slightly complicated, >> so clarify its use and centralize its parsing into the repo >> sett

Re: [PATCH 2/3] grep: stop "using" a custom JIT stack with PCRE v2

On Wed, Jul 24 2019, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> Since we've haven't had any reports of users running into >> PCRE2_ERROR_JIT_STACKLIMIT in the wild I think we can safely assume >> that we can just use the library defaults instead and drop this >> code. > > Doe

Re: [PATCH 0/3] grep: PCRE JIT fixes

On Wed, Jul 24 2019, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> There's a couple of patches fixing mistakes in the JIT code I added >> for PCRE in <20190722181923.21572-1-dev+...@drbeat.li> and >> <20190721194052.15440-1-care...@gmail.com> >> >> This small series proposes to

Re: [PATCH] grep: skip UTF8 checks explicitally

On Wed, Jul 24 2019, Johannes Schindelin wrote: > Hi Carlo, > > On Tue, 23 Jul 2019, Carlo Arenas wrote: > >> On Tue, Jul 23, 2019 at 5:47 AM Johannes Schindelin >> wrote: >> > >> > So when PCRE2 complains about the top two bits not being 0x80, it fails >> > to parse the bytes correctly (byte 2

Where do I send patches for git-gui?

Hi, I have a quick little feature to add to git-gui, and I'm wondering where should I discuss it and send patches. The git-gui repo [0] has no readme I can see that would point me in the right direction. Googling around didn't get me anything either. Should I send it here on this list or is

Hello

Hallo, ich hoffe du bekommst meine Nachrichtenvorschläge? Vielen Dank Michelle

Re: [PATCH 2/3] grep: stop "using" a custom JIT stack with PCRE v2

Ævar Arnfjörð Bjarmason writes: > Since we've haven't had any reports of users running into > PCRE2_ERROR_JIT_STACKLIMIT in the wild I think we can safely assume > that we can just use the library defaults instead and drop this > code. Does everybody use pcre2 with JIT with Git these days, or o

Re: [PATCH 0/3] grep: PCRE JIT fixes

Ævar Arnfjörð Bjarmason writes: > There's a couple of patches fixing mistakes in the JIT code I added > for PCRE in <20190722181923.21572-1-dev+...@drbeat.li> and > <20190721194052.15440-1-care...@gmail.com> > > This small series proposes to replace both of those. In both cases I > think we're b

Re: Need help

Hi Gobinda, if you have a consistent way to reproduce the issue, check out `git bisect`: https://git-scm.com/docs/git-bisect - Emily On Wed, Jul 24, 2019 at 12:11 AM Gobinda Nandi wrote: > > Hi, > > I have cloned a project using GIT. There I am facing one issue and nobody is > confident that

Re: [PATCH] grep: skip UTF8 checks explicitly

Johannes Schindelin writes: > My reading of the situation is slightly different. I think > PCRE_NO_UTF8_CHECK is off by default, but it only makes a difference in > the non-JIT'ed code path. Since we use PCRE2's JIT when possible > (because it leads to a quite nice performance improvement), we us

[ANNOUNCE] Git Rev News edition 53

Hi everyone, The 53rd edition of Git Rev News is now published: https://git.github.io/rev_news/2019/07/24/edition-53/ Thanks a lot to Jaime Rivas and Carlo Marcelo Arenas Belón who contributed this month! Enjoy, Christian, Jakub, Markus and Gabriel.

[PATCH 0/3] grep: PCRE JIT fixes

There's a couple of patches fixing mistakes in the JIT code I added for PCRE in <20190722181923.21572-1-dev+...@drbeat.li> and <20190721194052.15440-1-care...@gmail.com> This small series proposes to replace both of those. In both cases I think we're better off just removing the relevant code. The

[PATCH 1/3] grep: remove overly paranoid BUG(...) code

Remove code that would trigger if pcre_config() or pcre2_config() was so broken that "do we have JIT?" wouldn't return a boolean. I added this code back in fbaceaac47 ("grep: add support for the PCRE v1 JIT API", 2017-05-25) and then as noted in [1] incorrectly copy/pasted some of it in 94da9193a6

[PATCH 3/3] grep: stop using a custom JIT stack with PCRE v1

Simplify the PCRE v1 code for the same reasons as for the PCRE v2 code in the last commit. Unlike with v2 we actually used the custom stack in v1, but let's use PCRE's built-in 32 KB one instead, since experience with v2 shows that's enough. Most distros are already using v2 as a default, and the u

[PATCH 2/3] grep: stop "using" a custom JIT stack with PCRE v2

As reported in [1] the code I added in 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) to use a custom JIT stack has never worked. It was incorrectly copy/pasted from code I added in fbaceaac47 ("grep: add support for the PCRE v1 JIT API", 2017-05-25), which did work. Thus our intention o

Re: [GSoC][PATCH v2 2/2] rebase -i: support --committer-date-is-author-date

Hi Rohit On 23/07/2019 20:57, Rohit Ashiwal wrote: Hi Phillip On Sat, 20 Jul 2019 15:56:50 +0100 Phillip Wood wrote: [...] @@ -467,6 +470,9 @@ int cmd_rebase__interactive(int argc, const char **argv, const char *prefix) OPT_BOOL(0, "autosquash", &opts.autosquash,

Re: [RFC PATCH 0/9] rebase -i: extend rebase.missingCommitsCheck to `--edit-todo' and co.

Hi Alban Thanks for working on this, it's great to see you back on the list and I think it would be a useful addition to rebase. Unfortunately I'm not sure about this implementation though (although the early bug fix patches are useful in their own right) On 17/07/2019 15:39, Alban Gruin wro

Re: [GSoC][PATCH v2 1/1] rebase -i: add --ignore-whitespace flag

Hi Elijah & Rohit, On Tue, 23 Jul 2019, Elijah Newren wrote: > On Tue, Jul 23, 2019 at 1:01 PM Rohit Ashiwal > wrote: > > On Mon, 22 Jul 2019 11:00:40 +0100 Phillip Wood > > wrote: > > > [...] > > > > > > > @@ -489,6 +501,8 @@ int cmd_rebase__interactive(int argc, const char > > > > **argv, c

Re: [PATCH] grep: skip UTF8 checks explicitly

Hi Junio, On Tue, 23 Jul 2019, Junio C Hamano wrote: > Carlo Marcelo Arenas Belón writes: > > > Usually PCRE is compiled with JIT support, and therefore the code > > path used includes calling pcre2_jit_match (for PCRE2), that ignores > > invalid UTF-8 in the corpus. > > > > Make that option ex

Re: [PATCH] grep: skip UTF8 checks explicitally

Hi Carlo, On Tue, 23 Jul 2019, Carlo Arenas wrote: > On Tue, Jul 23, 2019 at 5:47 AM Johannes Schindelin > wrote: > > > > So when PCRE2 complains about the top two bits not being 0x80, it fails > > to parse the bytes correctly (byte 2 is 0xbb, whose two top bits are > > indeed 0x80). > > the err

Re: [PATCH 2/5] repo-settings: add feature.manyCommits setting

On 7/23/2019 10:53 AM, Johannes Schindelin wrote: > Hi Stolee, > > On Mon, 22 Jul 2019, Derrick Stolee via GitGitGadget wrote: > >> From: Derrick Stolee >> >> When a repo has many commits, it is helpful to write and read the >> commit-graph file. Future changes to Git may include new config >> s

blank lines in pre-created merge message

Hi! I think I had tried bringing this to your attention before, but I think it was without success. The issue may seem purely cosmetical, while being easy to fix (is my guess): When using "git merge --no-ff --no-commit ..", the pre-created merge message always contains two empty lines in between

Need help

Hi, I have cloned a project using GIT. There I am facing one issue and nobody is confident that when that issue was not there. They are convinced that earlier it was working well but noe its not. I am trying revert the version but still I am finding the issue. I know this can depend upon severa