Re: [PATCH] compat/regex: fix compilation on Windows

Johannes Schindelin writes: > The real issue here is that GNU awk's regex implementation assumes a bit > too much about the relative sizes of pointers and long integers. What they > really want is to use intptr_t. Good. I got annoyed enough to do the same myself

Re: What's cooking in git.git (May 2017, #03; Wed, 10)

On Thu, May 11, 2017 at 05:31:45PM -0400, Marc Branchaud wrote: > > * mb/diff-default-to-indent-heuristics (2017-05-09) 4 commits > [...] > > Kicked out of next; it seems it is still getting review suggestions? > > I believe v4 of this one is ready to cook. Yeah, I think it's ready, too (and I

Re: Best "triangle" workflow setup?

On Thu, May 11, 2017 at 04:23:03PM -0500, Robert Dailey wrote: > On Thu, May 11, 2017 at 3:17 PM, Jeff King wrote: > > I think you want: > > > > [push] > > default = current > > [remote] > > pushDefault = myfork > > > > to make "git push" do what you want. And then

Re: Possible bug in includeIf / conditional includes on non git initialised directories

On Thu, May 11, 2017 at 10:31:14PM +0200, Sebastian Schuberth wrote: > On 2017-05-11 20:53, Raphael Stolt wrote: > > > I might have stumbled this time over a real bug in includeIf / conditional > > includes or maybe it's just as intended. > > 1) Given I have a correct configured includeIf and

Re: [PATCH 09/29] grep: amend submodule recursion test for regex engine testing

Ævar Arnfjörð Bjarmason writes: > 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->

Re: [PATCH 1/7] compat/regex: add a README with a maintenance guide

Ævar Arnfjörð Bjarmason writes: > diff --git a/compat/regex/README b/compat/regex/README > new file mode 100644 > index 00..345d322d8c > --- /dev/null > +++ b/compat/regex/README > @@ -0,0 +1,21 @@ > +This is the Git project's copy of the GNU awk (Gawk) regex >

Re: [PATCH 8/8] pathspec: convert parse_pathspec to take an index

Brandon Williams writes: > ... Note that if we go with the route to not pass > in an index now, it doesn't necessarily mean that down the line we won't > have to pass a 'repository' instance into parse_pathspec(). Correct. An attribute annotated pathspec may want to check

Re: [RFC] send-email: support validate hook

Jonathan Tan writes: > diff --git a/git-send-email.perl b/git-send-email.perl > index eea0a517f..7de91ca7c 100755 > --- a/git-send-email.perl > +++ b/git-send-email.perl > @@ -27,6 +27,7 @@ use Term::ANSIColor; > use File::Temp qw/ tempdir tempfile /; > use

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

On Thu, May 11, 2017 at 03:46:39PM -0700, Jonathan Nieder wrote: > > +static void add_refs_to_oidset(struct oidset *oids, struct ref *refs) > > +{ > > + for (; refs; refs = refs->next) > > + oidset_insert(oids, >old_oid); > > +} > > + > > +static int tip_oids_contain(struct oidset

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

Ævar Arnfjörð Bjarmason writes: > Add exhaustive tests for how the different grep.patternType options & > the corresponding command-line options affect git-log. > ... > The patterns being passed to fixed/basic/extended/PCRE are carefully > crafted to return the wrong thing if

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

Jonathan Tan wrote: [...] > --- a/fetch-pack.c > +++ b/fetch-pack.c > @@ -15,6 +15,7 @@ > #include "version.h" > #include "prio-queue.h" > #include "sha1-array.h" > +#include "oidset.h" > > static int transfer_unpack_limit = -1; > static int fetch_unpack_limit = -1; > @@ -592,13 +593,32 @@

Re: What's cooking in git.git (May 2017, #03; Wed, 10)

Jeff King writes: > On Thu, May 11, 2017 at 05:31:45PM -0400, Marc Branchaud wrote: > >> > * mb/diff-default-to-indent-heuristics (2017-05-09) 4 commits >> [...] >> > Kicked out of next; it seems it is still getting review suggestions? >> >> I believe v4 of this one is ready to

Re: [PATCH 11/29] grep: add a test helper function for less verbose -f \0 tests

Ævar Arnfjörð Bjarmason writes: > 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

Re: [PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Johannes Schindelin writes: > Git uses the config for remote/upstream information in favor of the > previously-used .git/remotes/ and .git/branches/ for a decade now. The last time I thought about trying this several years ago, I found that people who need to grab

[PATCH 3/3] commit.c: skip scissors when computing trailers

"scissors" ("- >8 -") can be automatically added to commit messages by setting commit.verbose = true. Prevent this from interfering with trailer calculations by automatically skipping over scissors, instead of (usually) treating them as a comment. --- commit.c | 13

[PATCH 1/3] mailinfo.c: is_scissors_line ends on newline

Needed to work with git interpret-trailers. Since "line" is, of course, a line, it will always end with "\n\0" and therefore we can safely end on "\n". --- mailinfo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mailinfo.c b/mailinfo.c index a489d9d0f..eadd0597f 100644 ---

[PATCH 0/3] interpret-trailers + commit -v bugfix

Hi all, This patch series addresses a bug in interpret-trailers. If the commit that is being editted is "verbose", it will contain a scissors string ("-- >8 --") and a diff. interpret-trailers doesn't interpret the scissors and therefore places trailer information after the diff. A simple

[PATCH 2/3] commit.c: add is_scissors_line

Move is_scissors_line to commit.c and expose it through commit.h. This is needed in commit.c, and mailinfo.c shouldn't really own it. --- commit.c | 52 commit.h | 1 + mailinfo.c | 53 +

[PATCH v5] fetch-pack: always allow fetching of literal SHA1s

fetch-pack, when fetching a literal SHA-1 from a server that is not configured with uploadpack.allowtipsha1inwant (or similar), always returns an error message of the form "Server does not allow request for unadvertised object %s". However, it is sometimes the case that such object is advertised.

Re: [PATCH 0/7] Update the compat/regex engine from upstream

Ævar Arnfjörð Bjarmason writes: > See the first patch for motivation & why. > ... I do not necessarily agree with the upgrading strategy outlined in 1/7, but that is a separate issue. There may be some other bits that needs resurrecting out of "git log -p master

Re: [PATCH v5] fetch-pack: always allow fetching of literal SHA1s

On Thu, May 11, 2017 at 03:30:54PM -0700, Jonathan Tan wrote: > fetch-pack, when fetching a literal SHA-1 from a server that is not > configured with uploadpack.allowtipsha1inwant (or similar), always > returns an error message of the form "Server does not allow request for > unadvertised object

Re: [PATCH] C style: use standard style for "TRANSLATORS" comments

Am 11.05.2017 um 23:20 schrieb Ævar Arnfjörð Bjarmason: diff --git a/builtin/notes.c b/builtin/notes.c index 7b891471c4..fb856e53b6 100644 --- a/builtin/notes.c +++ b/builtin/notes.c @@ -340,8 +340,10 @@ static struct notes_tree *init_notes_check(const char *subcommand, ref = (flags &

Re: What's cooking in git.git (May 2017, #03; Wed, 10)

Johannes Schindelin writes: > Hi Junio, > > On Wed, 10 May 2017, Junio C Hamano wrote: > >> * jc/bundle (2016-03-03) 6 commits >> - index-pack: --clone-bundle option >> - Merge branch 'jc/index-pack' into jc/bundle >> - bundle v3: the beginning >> - bundle: keep a

Re: [PATCH v2 0/6] convert pathspec.c to take an index parameter

Brandon Williams writes: > The main difference in v2 is that instead of piping through an index_state > struct into parse_pathspec, I ripped out the logic that needed to access the > index and either removed it completely if it wasn't needed anymore (stripping > submodule

[PATCH 4/4] docs/config: consistify include.path examples

Most of the include examples use "foo.inc", but some use "foo". Since the string of examples are meant to show variations and how they differ, it's a good idea to change only one thing at a time. The filename differences are not relevant to what we're trying to show. Signed-off-by: Jeff King

Re: Should "git submodule update" accepts --init?

Nazri Ramliy writes: > Otherwise it seems like I'll have to do "git submodule update" twice > in order to update an already initialized submodule whose upstream > repo url has been updated in .gitmodules to point to somewhere new, I am not a heavy submodule user so what I

Re: Should "git submodule update" accepts --init?

On Thu, May 11, 2017 at 2:42 PM, Junio C Hamano wrote: > I am not a heavy submodule user so what I think may not count, but I > think the "upstream" changing the URL of the submodule should be a > rare and notable event. Making it easy to automatically run "sync" > without

[PATCH 3/4] docs/config: avoid the term "expand" for includes

Using the word "expand" to refer to including the contents of another config file isn't really accurate, since it's a verbatim insertion. And it can cause confusion with the expanding of the path itself via things like "~". Let's clarify when we are referring to the contents versus the filename,

Should "git submodule update" accepts --init?

Hi, The command "git submodule update" accepts an "--init" flag to initialize an uninitialized submodules. Shouldn't it also accept "--sync" flag in order to sync and unsync'd submodule? Otherwise it seems like I'll have to do "git submodule update" twice in order to update an already

Re: Possible bug in includeIf / conditional includes

On Thu, May 11, 2017 at 02:26:16AM -0400, Jeff King wrote: > > So whether this is a bug in the code or not it seems to definitely be > > a doc bug, whatever it does with relative files should be in the docs. > > The includeIf variables should behave exactly as the documentation you > quoted

[PATCH v3 1/2] perf: add function to setup a fresh test repo

Add a function to setup a fresh test repo via 'git init' to compliment the existing functions to copy over a normal & large repo. Some performance tests don't need any existing repository data at all to be significant, e.g. tests which stress glob matches against single pathological revisions or

[PATCH v3 0/2] perf: show that wildmatch() regressed for pathological cases in v2.0

Fixes the issues noted in v3, see <20170510225316.31680-1-ava...@gmail.com> (https://public-inbox.org/git/20170510225316.31680-1-ava...@gmail.com/). In addition I was wrong about for-each-ref not being subjected to this slowdown, I was just screwing up the testcase. Fix that. Now: $

Re: Possible bug in includeIf / conditional includes

On Thu, May 11, 2017 at 09:19:50AM +0200, Ævar Arnfjörð Bjarmason wrote: > 1. It says "The included file is expanded immediately, as if its > contents had been found at the location of the include directive.". At > first I thought this referred to glob expansion, not > s/expanded/interpolated/,

[PATCH v3 2/2] perf: add test showing exponential growth in path globbing

Add a test showing that runtimes of the wildmatch() function used for globbing in git grow exponentially in the face of some pathological globs. This issue affects both globs matching filenames via e.g. ls-files, and globs matching refnames via e.g. for-each-ref. As noted in the test description

Re: Possible bug in includeIf / conditional includes

On Thu, May 11, 2017 at 12:54:19AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Thu, May 11, 2017 at 09:19:50AM +0200, Ævar Arnfjörð Bjarmason wrote: > > > >> 1. It says "The included file is expanded immediately, as if its > >> contents had been found at the

Re: https://travis-ci.org/git/git/builds/

On Thu, May 11, 2017 at 9:46 AM, Junio C Hamano wrote: > I was hoping that by ejecting a few topics out of 'pu', we could > finally see all the build jobs pass their tests under Travis CI. > Unfortunately, no such luck. It seems that we have some new issues > with

[PATCH 1/4] docs/config: clarify include/includeIf relationship

The "includeIf" directives behave exactly like include ones, except they only kick in when the conditional is true. That was mentioned in the "conditional" section, but let's make it more clear for the whole "includes" section, since people don't necessarily read the documentation top to bottom.

[PATCH 2/4] docs/config: give a relative includeIf example

The changes in the previous commit hopefully clarify that the evaluation of an include "path" variable is the same no matter if it's in a conditional section or not. But since this question came up on the list, let's add an example that makes it obvious. Signed-off-by: Jeff King

Re: Possible bug in includeIf / conditional includes

On Wed, May 10, 2017 at 09:48:05PM +0200, Ævar Arnfjörð Bjarmason wrote: > In both cases the conditional is the same, but the path is relative > v.s. absolute. > > Raphael: Does the config get included if you cd to > ~/Work/git-repos/oss/? From git-config(1): That shouldn't matter for relative

Re: git log --follow after subtree merge

On Thu, May 11, 2017 at 02:35:49AM -0400, Jeff King wrote: > > > After doing a subtree merge, using 'git log' and 'git log --follow' on > > > files in the subtree show only the merge commit in which they were > > > added. > > > > > > After reading around I understand that the issue is that git

[PATCH 0/4] doc improvements for config includes

On Thu, May 11, 2017 at 03:54:37AM -0400, Jeff King wrote: > On Thu, May 11, 2017 at 09:49:09AM +0200, Ævar Arnfjörð Bjarmason wrote: > > > > I don't like this because it copies the rules for _one_ property to the > > > conditional section. What happens when you're looking for some other > > >

Re: git log --follow after subtree merge

On Wed, May 10, 2017 at 02:15:23PM -0500, Samuel Lijin wrote: > On Wed, May 10, 2017 at 9:46 AM, Jonny Gilchrist > wrote: > > Hi, > > > > After doing a subtree merge, using 'git log' and 'git log --follow' on > > files in the subtree show only the merge commit in which

Re: Possible bug in includeIf / conditional includes

On Thu, May 11, 2017 at 9:42 AM, Jeff King wrote: > On Thu, May 11, 2017 at 09:19:50AM +0200, Ævar Arnfjörð Bjarmason wrote: > >> 1. It says "The included file is expanded immediately, as if its >> contents had been found at the location of the include directive.". At >> first I

Re: git log --follow after subtree merge

On Wed, May 10, 2017 at 02:15:23PM -0500, Samuel Lijin wrote: > On Wed, May 10, 2017 at 9:46 AM, Jonny Gilchrist > wrote: > > Hi, > > > > After doing a subtree merge, using 'git log' and 'git log --follow' on > > files in the subtree show only the merge commit in which

Re: Possible bug in includeIf / conditional includes

On Thu, May 11, 2017 at 8:29 AM, Jeff King wrote: > On Thu, May 11, 2017 at 02:26:16AM -0400, Jeff King wrote: > >> > So whether this is a bug in the code or not it seems to definitely be >> > a doc bug, whatever it does with relative files should be in the docs. >> >> The

https://travis-ci.org/git/git/builds/

I was hoping that by ejecting a few topics out of 'pu', we could finally see all the build jobs pass their tests under Travis CI. Unfortunately, no such luck. It seems that we have some new issues with Gettext-Poison build/test after updates to t0027. Also the updated compatibility regexp thing

Re: Possible bug in includeIf / conditional includes

On Thu, May 11, 2017 at 09:49:09AM +0200, Ævar Arnfjörð Bjarmason wrote: > > I don't like this because it copies the rules for _one_ property to the > > conditional section. What happens when you're looking for some other > > property of include.path? > > Yeah, as I said once I wrote it up I

Re: Possible bug in includeIf / conditional includes

Jeff King writes: > On Thu, May 11, 2017 at 09:19:50AM +0200, Ævar Arnfjörð Bjarmason wrote: > >> 1. It says "The included file is expanded immediately, as if its >> contents had been found at the location of the include directive.". At >> first I thought this referred to glob

[BUG] fast-export --anonymize does not maintain fixup! commits

Hi, I just tried to created an anonymized repo to allow the list to reproduce a bug in "rebase -i" I discovered in Git 2.13 for Linux (Windows is not affected). However, in order to reproduce the bug it's important to keep the "fixup!" prefixes as part of the commit messages. Unfortunately,

Re: [PATCH] compat/regex: fix compilation on Windows

On Thu, May 11, 2017 at 3:50 PM, Johannes Schindelin wrote: > The real issue here is that GNU awk's regex implementation assumes a bit > too much about the relative sizes of pointers and long integers. What they > really want is to use intptr_t. Thanks, looks good! >

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

Easy to review? 29 patches? Are you kidding me?! I thought about how to split up my sprawling PCRE v2 series which can't easily be broken up because a lot of it is trivial setup code needed for later patches, or things that would result in lots of merge conflicts. This is an attempt to make that

[PATCH 06/29] 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 ---

Re: [PATCH v3] fetch-pack: always allow fetching of literal SHA1s

On Wed, May 10, 2017 at 03:11:57PM -0700, Jonathan Tan wrote: > After looking at ways to solve jrnieder's performance concerns, if we're > going to need to manage one more item of state within the function, I > might as well use my earlier idea of storing unmatched refs in its own > list instead

Re: What's cooking in git.git (May 2017, #03; Wed, 10)

Hi, [making sure Lars reads this] On Wed, 10 May 2017, Junio C Hamano wrote: > * ls/filter-process-delayed (2017-03-06) 1 commit > - convert: add "status=delayed" to filter process protocol > > What's the status of this one??? > cf. Ciao,

[PATCH 07/11] PREVIEW: t5516: stop testing .git/branches/ functionality

We are about to remove support for .git/remotes/ and .git/branches/, at long last. In preparation for this move, let's remove the corresponding regression tests from t5516-fetch-push. Note: the `push --prune` test case (and another test case after that) relied on the side effect where a branch

[PATCH 08/11] PREVIEW: remote: remove support for migrating ancient remotes

By now, everybody will have moved on... no need to burden ourselves with now-obsolete code. Signed-off-by: Johannes Schindelin --- Documentation/git-remote.txt | 4 builtin/remote.c | 27 - t/t5505-remote.sh| 57

HELLO! DEAR! GOOD NEWS TO YOU,

HELLO! DEAR! GOOD NEWS TO YOU, Your ATM Card of $5.5 million USD has been approved and was deposited with fidEX delivery company this morning for registration,and we agreed up that the delivery of Your $5.5 Million USD ATM Package will take off tomorrow morning .So contact with your

[PATCH 09/11] PREVIEW: t5515: remove .git/remotes/ and .git/branches/ tests

We are about to remove support for the long-obsolete .git/remotes/ and .git/branches/ directories. Let's stop testing them, in preparation for that move. The bulk of this patch simply removes support files that are no longer needed. Signed-off-by: Johannes Schindelin

[PATCH 05/11] Revert "Revert "Don't create the $GIT_DIR/branches directory on init""

A long, long, long time ago, we stored the "upstream" information of branches in files inside the .git/branches/ directory. We don't do this anymore, though. Since 5751f49010e (Move remote parsing into a library file out of builtin-push., 2007-05-12), to be precise. This is sort of a sibling to

[PATCH 00/11] Start retiring .git/remotes/ and .git/branches/ for good

Git uses the config for remote/upstream information in favor of the previously-used .git/remotes/ and .git/branches/ for a decade now. Nothing in Git writes to these files any longer, and the most prominent user of .git/branches/ (Cogito) is long abandoned. It is time to start not only

[PATCH 04/11] remote: warn loud and clear when .git/remotes/ is *still* used

Since at least 75c384efb52 (Do not create $GIT_DIR/remotes/ directory anymore., 2006-12-19), we strongly prefer remotes and upstream branches to be specified in the config rather than .git/remotes/ and .git/branches/. For some time, we still retained backwards-compatibility. At some stage, it

[PATCH 11/11] PREVIEW: remove support for .git/remotes/ and .git/branches/

At long last, after a cycle or three of warning users who *still* use the ancient feature of .git/remotes/ and .git/branches/, it is time to retire the code. Signed-off-by: Johannes Schindelin --- path.c | 2 -- remote.c | 96

[PATCH 01/11] git-parse-remote: fix highly misleading man page

The man page still talked about the .git/remotes/ directory (which is no longer in use, as of 75c384efb52 (Do not create $GIT_DIR/remotes/ directory anymore., 2006-12-19)). Let's just revamp it almost completely to reflect the *purpose* of that scriptlet, as opposed to its implementation details.

[PATCH 03/11] remote: warn loud and clear when .git/branches/ is *still* used

Since at least 5751f49010e (Move remote parsing into a library file out of builtin-push., 2007-05-12), we strongly prefer remotes and upstream branches to be specified in the config rather than .git/remotes/ and .git/branches/. For some time, we still retained compatibility with Cogito (which was

[PATCH 02/11] Documentation: really deprecate .git/remotes/ and .git/branches/

The documentation did not make it quite clear just how deprecated these directories are. Signed-off-by: Johannes Schindelin --- Documentation/gitrepository-layout.txt | 19 +- Documentation/urls-remotes.txt | 65 ++ 2

[PATCH 10/11] PREVIEW: t0060: stop testing support for .git/remotes/ and .git/branches/

We are about to remove that feature for good. Signed-off-by: Johannes Schindelin --- t/t0060-path-utils.sh | 2 -- 1 file changed, 2 deletions(-) diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh index 444b5a4df80..162c9a5a2f7 100755 ---

[PATCH 06/11] PREVIEW: t5510: convert .git/remotes/ test to use a regular remote

We are about to stop supporting the .git/remotes/ and .git/branches/ feature. In preparation, t5510-fetch is adjusted *not* to verify that .git/remotes/ works. As the tests are entangled, we do not simply remove the test repository with such a remote, but convert it to use a regular remote

git-log(1) Doesn't Describe -L start,end Fully.

Hi, Arch Linux's git 2.12.2-4's git-log(1) says -L ,:, -L :: Trace the evolution of the line range given by "," (or the function name regex ) within the . You may not give any pathspec limiters. This is currently limited to a walk starting from a single

Re: What's cooking in git.git (May 2017, #03; Wed, 10)

Hi Junio, On Wed, 10 May 2017, Junio C Hamano wrote: > * jc/bundle (2016-03-03) 6 commits > - index-pack: --clone-bundle option > - Merge branch 'jc/index-pack' into jc/bundle > - bundle v3: the beginning > - bundle: keep a copy of bundle file name in the in-core bundle header > - bundle:

[PATCH] compat/regex: fix compilation on Windows

The real issue here is that GNU awk's regex implementation assumes a bit too much about the relative sizes of pointers and long integers. What they really want is to use intptr_t. This patch recapitulates what 56a1a3ab449 (Silence GCC's "cast of pointer to integer of a different size" warning,

Re: What's cooking in git.git (May 2017, #03; Wed, 10)

> On 11 May 2017, at 14:09, Johannes Schindelin > wrote: > > Hi, > > [making sure Lars reads this] > > On Wed, 10 May 2017, Junio C Hamano wrote: > >> * ls/filter-process-delayed (2017-03-06) 1 commit >> - convert: add "status=delayed" to filter process protocol

Re: [PATCH 1/4] docs/config: clarify include/includeIf relationship

On 11/05/17 10:10, Jeff King wrote: > The "includeIf" directives behave exactly like include ones, > except they only kick in when the conditional is true. That > was mentioned in the "conditional" section, but let's make > it more clear for the whole "includes" section, since people > don't

Re: [PATCH v3] fetch-pack: always allow fetching of literal SHA1s

On 05/11, Jeff King wrote: > On Wed, May 10, 2017 at 03:11:57PM -0700, Jonathan Tan wrote: > > > fetch-pack, when fetching a literal SHA-1 from a server that is not > > configured with uploadpack.allowtipsha1inwant (or similar), always > > returns an error message of the form "Server does not

[PATCH 4/7] grep: add support for the PCRE v1 JIT API

Change the grep PCRE v1 code to use JIT when available. When PCRE support was initially added in commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) PCRE had no JIT support, it was integrated into 8.20 released on 2011-10-21. Enabling JIT support usually improves performance by more than 40%.

[PATCH 5/7] grep: un-break building with PCRE < 8.32

Amend my change earlier in this series ("grep: add support for the PCRE v1 JIT API", 2017-04-11) to un-break the build on PCRE v1 versions earlier than 8.32. The JIT support was added in version 8.20 released on 2011-10-21, but it wasn't until 8.32 released on 2012-11-30 that the fast code path

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

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 while the API is similar, pretty much every function is either renamed or takes different arguments. Thus using it via entirely new functions

[PATCH 3/7] log: add -P as a synonym for --perl-regexp

Add a short -P option as a synonym for the longer --perl-regexp, for consistency with the options the corresponding grep invocations accept. This was intentionally omitted in commit 727b6fc3ed ("log --grep: accept --basic-regexp and --perl-regexp", 2012-10-03) for unspecified future use. Make it

[PATCH 6/7] grep: un-break building with PCRE < 8.20

Amend my change earlier in this series ("grep: add support for the PCRE v1 JIT API", 2017-04-11) to un-break the build on PCRE v1 versions earlier than 8.20. The 8.20 release was the first release to have JIT & pcre_jit_stack in the headers, so a mock type needs to be provided for it on those

Re: [PATCH 01/11] git-parse-remote: fix highly misleading man page

On Thu, May 11, 2017 at 6:47 AM, Johannes Schindelin wrote: > The man page still talked about the .git/remotes/ directory (which is no > longer in use, as of 75c384efb52 (Do not create $GIT_DIR/remotes/ > directory anymore., 2006-12-19)). > > Let's just revamp it

Re: [PATCH 05/11] Revert "Revert "Don't create the $GIT_DIR/branches directory on init""

On Thu, May 11, 2017 at 6:47 AM, Johannes Schindelin wrote: > A long, long, long time ago, we stored the "upstream" information of > branches in files inside the .git/branches/ directory. We don't do this > anymore, though. Since 5751f49010e (Move remote parsing into a

Re: Article on the branch strategy in gitworkflows(7)

FYI - the article mentioned below has been published @ https://medium.com/@ramangupta/how-the-creators-of-git-do-branches-e6fcc57270fb Thank you to the two or three people that I know of that took the time to read the draft. Regards, Raman On 22/03/17 12:41 PM, Raman Gupta wrote: > Several

[PATCH] pull: optionally rebase submodules

Teach pull to optionally update submodules when '--recurse-submodules' is provided. This will teach pull to run 'submodule update --rebase' when the '--recurse-submodules' and '--rebase' flags are given. Signed-off-by: Brandon Williams --- Pull is already a shortcut for

[PATCH 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.

[PATCH 0/7] PCRE v2, PCRE v1 JIT, log -P & fixes

This goes on top of the 29 patch series of "Easy to review grep & pre-PCRE changes" (<20170511091829.5634-1-ava...@gmail.com>; https://public-inbox.org/git/20170511091829.5634-1-ava...@gmail.com/). This could be split into 3 unrelated things, but I have think it's probably easier for everyone to

[PATCH 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 01/29] 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 03/29] 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 02/29] 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 04/29] 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 v3 2/3] read-tree -m: make error message for merging 0 trees less smart aleck

"git read-tree -m" requires a tree argument to name the tree to be merged in. Git uses a cutesy error message to say so and why: $ git read-tree -m warning: read-tree: emptying the index with no arguments is deprecated; use --empty fatal: just how do you expect me to merge 0

[PATCH v3 3/3] git-filter-branch:

git-filter-branch requires the specification of a branch by one way or another. If no branch appears to have been specified, we know the user got the usage wrong but we don't know what they were trying to do --- e.g. maybe they specified the ref to rewrite but in the wrong place. In this case,

[PATCH v3 1/3] usability: don't ask questions if no reply is required

There has been a bug report by a corporate user that stated that "spelling mistake of stash followed by a yes prints character 'y' infinite times." This analysis was false. When the spelling of a command contains errors, the git program tries to help the user by providing candidates which are

Re: [PATCH v2 1/2] perf: add function to setup a fresh test repo

Ævar Arnfjörð Bjarmason writes: > On Thu, May 11, 2017 at 1:30 AM, Jonathan Nieder wrote: >> Hi, >> >> Ęvar Arnfjörš Bjarmason wrote: >> >> [...] >>> # call at least one of these to establish an appropriately-sized repository >>> +test_perf_fresh_repo () {

RE: [PATCH v2 1/3] usability: don't ask questions if no reply is required

Some more grammar/usage notes . > -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On > Behalf Of Junio C Hamano > Sent: Thursday, May 11, 2017 4:16 AM > To: Jean-Noel Avila > Cc: git@vger.kernel.org; rashmipa...@gmail.com >

[PATCH 10/29] 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 12/29] 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 13/29] grep: add tests to fix blind spots with \0 patterns

Address a big blind spot in the tests for patterns containing \0. The is_fixed() function considers any string that contains \0 fixed, even if it contains regular expression metacharacters, those patterns are currently matched with kwset. Before this change removing that memchr(s, 0, len) check

[PATCH 18/29] 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 09/29] 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 21/29] 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 limitation was never documented, and other some regular expression engines are capable of compiling

  1   2   >