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

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

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

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

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 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: [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] 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: [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

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 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: [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 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: 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: 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: [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 @@

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

[PATCH v2 5/6] pathspec: remove PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP

Since (ae8d08242 pathspec: pass directory indicator to match_pathspec_item()) the path matching logic has been able to cope with submodules without needing to strip off a trailing slash if a path refers to a submodule. Since stripping the slash is no longer necessary, remove the

clone vs submodule operation with HTTP cURL

Hello everyone, In our usage of GSSAPI via HTTPS, all our operation with git are very well handle, however, when trying to update a submodule, git seems to be managing cURL differently. cURL drop the ball quickly. Example (No other setup needed on the client) : git clone HTTPrepo -> GET -> 401

[PATCH v2 6/6] pathspec: convert find_pathspecs_matching_against_index to take an index

Convert find_pathspecs_matching_against_index to take an index parameter. In addition mark pathspec.c with NO_THE_INDEX_COMPATIBILITY_MACROS now that it doesn't use any cache macros or reference 'the_index'. Signed-off-by: Brandon Williams --- builtin/add.c | 4

[PATCH v2 1/6] pathspec: provide a more descriptive die message

The current message displayed upon an internal error in 'init_pathspec_item()' isn't very descriptive and doesn't provide much context to where the error occurred. Update the error message to provide more context to where the error occured. Signed-off-by: Brandon Williams ---

[PATCH v2 2/6] submodule: add die_in_unpopulated_submodule function

Currently 'git add' is the only command which dies when launched from an unpopulated submodule (the place-holder directory for a submodule which hasn't been checked out). This is triggered implicitly by passing the PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE flag to 'parse_pathspec()'. Instead make

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

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 slash) or factored it out into its own function which can

[PATCH v2 3/6] pathspec: remove PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE flag

Since (ae8d08242 pathspec: pass directory indicator to match_pathspec_item()) the path matching logic has been able to cope with submodules without needing to strip off a trailing slash if a path refers to a submodule. Since the stripping the trailing slash is no longer necessary, remove the

[PATCH v2 4/6] ls-files: prevent prune_cache from overeagerly pruning submodules

Since (ae8d08242 pathspec: pass directory indicator to match_pathspec_item()) the path matching logic has been able to cope with submodules without needing to strip off a trailing slash if a path refers to a submodule. ls-files is the only caller of 'parse_pathspec()' which relies on the behavior

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

On Thu, May 11, 2017 at 02:35:17PM -0700, Jonathan Nieder wrote: > This structure could be simplified by putting the lazy-initializing > tip_oids lookup in a separate function. For example: > > int tip_oids_contain(struct oidset *tip_oids, > struct ref *unmatched, struct ref

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

On 05/11, Jonathan Nieder wrote: > Hi, > > Ævar Arnfjörð Bjarmason wrote: > > > Change all the "TRANSLATORS: [...]" comments in the C code to use the > > regular Git coding style, and amend the style guide so that the > > example there uses that style. > > Hooray! > > [...] > > ---

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

Hi, Ævar Arnfjörð Bjarmason wrote: > Change all the "TRANSLATORS: [...]" comments in the C code to use the > regular Git coding style, and amend the style guide so that the > example there uses that style. Hooray! [...] > --- a/Documentation/CodingGuidelines > +++

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

Hi, Jonathan Tan wrote: > Thanks, peff. I've incorporated your suggestions - I don't feel very > strongly about this, but I guess it's worthwhile to avoid the quadratic > behavior if we can. > > Also incorporated Jonathan Nieder's suggestion about the placement of > the last line. The relevant

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

On 2017-05-10 01:18 AM, Junio C Hamano wrote: * mb/diff-default-to-indent-heuristics (2017-05-09) 4 commits - add--interactive: drop diff.indentHeuristic handling - diff: enable indent heuristic by default - diff: have the diff-* builtins configure diff before initializing revisions - diff:

Re: Best "triangle" workflow setup?

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 generally have branches > mark their counterparts on "origin" (which you can do either at

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

Change all the "TRANSLATORS: [...]" comments in the C code to use the regular Git coding style, and amend the style guide so that the example there uses that style. This custom style was necessary back in 2010 when the gettext support was initially added, and was subsequently documented in commit

[PATCH v4] 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] fetch-pack: always allow fetching of literal SHA1s

On Thu, May 11, 2017 at 12:03:54PM -0700, Jonathan Nieder wrote: > > But even leaving all the refs/pull stuff aside, allowAnySHA1InWant does > > seem to increase that confusion, and I don't see a way around it short > > of never sharing objects between repositories at all. So I think at most > >

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

On Thu, May 11, 2017 at 10:51:37AM -0700, Jonathan Tan wrote: > > This is inside the nr_sought loop. So if I were to do: > > > > git fetch origin $(git ls-remote origin | awk '{print $1}') > > > > we're back to being quadratic. I realize that's probably a silly thing > > to do, but in the

Re: [PATCH 18/29] grep: catch a missing enum in switch statement

On Thu, May 11, 2017 at 10:40 PM, Stefan Beller wrote: > On Thu, May 11, 2017 at 1:08 PM, Brandon Williams wrote: >> On 05/11, Ævar Arnfjörð Bjarmason wrote: >>> Add a die(...) to a default case for the switch statement selecting >>> between grep pattern

Re: [PATCH 28/29] grep: given --threads with NO_PTHREADS=YesPlease, warn

On 05/11, Ævar Arnfjörð Bjarmason wrote: > On Thu, May 11, 2017 at 10:21 PM, Brandon Williams wrote: > > On 05/11, Ævar Arnfjörð Bjarmason wrote: > >> Add a warning about missing thread support when grep.threads or > >> --threads is set to a non 0 (default) or 1 (no

Re: [PATCH 18/29] grep: catch a missing enum in switch statement

On Thu, May 11, 2017 at 1:08 PM, Brandon Williams wrote: > On 05/11, Ævar Arnfjörð Bjarmason wrote: >> 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,

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

On 05/11, Jonathan Tan wrote: > Currently, send-email has support for rudimentary e-mail validation. > Allow the user to add support for more validation by providing a > sendemail-validate hook. > > Signed-off-by: Jonathan Tan > --- > > This is motivated by situations

Re: [PATCH 26/29] pack-objects & index-pack: add test for --threads warning

On Thu, May 11, 2017 at 10:17 PM, Brandon Williams wrote: > On 05/11, Ævar Arnfjörð Bjarmason wrote: >> 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

Re: [PATCH 28/29] grep: given --threads with NO_PTHREADS=YesPlease, warn

On Thu, May 11, 2017 at 10:21 PM, Brandon Williams wrote: > On 05/11, Ævar Arnfjörð Bjarmason wrote: >> 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. >> >>

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

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 I’m issuing `git config > --show-origin --get user.email` against an directory

Re: [PATCH 21/29] grep: factor test for \0 in grep patterns into a function

On Thu, May 11, 2017 at 10:15 PM, Brandon Williams wrote: > On 05/11, Ævar Arnfjörð Bjarmason wrote: >> 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

Re: [PATCH 28/29] grep: given --threads with NO_PTHREADS=YesPlease, warn

On 05/11, Ævar Arnfjörð Bjarmason wrote: > 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

Re: [PATCH 24/29] grep: move two functions to avoid forward declaration

On Thu, May 11, 2017 at 10:14 PM, Brandon Williams wrote: > On 05/11, Ævar Arnfjörð Bjarmason wrote: >> Move the is_fixed() and has_null() functions which are currently only >> used in compile_regexp() earlier so they can be used in the PCRE >> family of functions in a later

Re: [PATCH 26/29] pack-objects & index-pack: add test for --threads warning

On 05/11, Ævar Arnfjörð Bjarmason wrote: > 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

Re: Best "triangle" workflow setup?

On Thu, May 11, 2017 at 02:41:41PM -0500, Robert Dailey wrote: > What I want (as a default) is for `git pull` to pull from the > same-named branch on the upstream repository, but for `git push` to > push to the same-named branch on the fork repository. However to > override this behavior for when

Re: [PATCH 21/29] grep: factor test for \0 in grep patterns into a function

On 05/11, Ævar Arnfjörð Bjarmason wrote: > 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

Re: [PATCH 24/29] grep: move two functions to avoid forward declaration

On 05/11, Ævar Arnfjörð Bjarmason wrote: > Move the is_fixed() and has_null() functions which are currently only > used in compile_regexp() earlier so they can be used in the PCRE > family of functions in a later change. > > Signed-off-by: Ævar Arnfjörð Bjarmason > --- >

Re: [PATCH 22/29] grep: change the internal PCRE macro names to be PCRE1

On 05/11, Ævar Arnfjörð Bjarmason wrote: > 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

Re: [PATCH 18/29] grep: catch a missing enum in switch statement

On 05/11, Ævar Arnfjörð Bjarmason wrote: > 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

Re: [PATCH 07/29] grep: change non-ASCII -i test to stop using --debug

On 05/11, Ævar Arnfjörð Bjarmason wrote: > Thanks a lot for looking this giant deluge of patches over. No problem, I'm no expert in some of the areas you're touching but at least I can catch little things like this :) -- Brandon Williams

Re: [PATCH] pull: optionally rebase submodules

From: "Brandon Williams" 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

Best "triangle" workflow setup?

I know Git has evolved to support the "triangle" workflow model in different ways, with the goal of making it better. However because there are so many different options from separate push URLs for remotes to various ways to manage tracking branches, it's not clear to me which specific

[RFC] send-email: support validate hook

Currently, send-email has support for rudimentary e-mail validation. Allow the user to add support for more validation by providing a sendemail-validate hook. Signed-off-by: Jonathan Tan --- This is motivated by situations in which we discuss a work in progress using

Re: [PATCH 08/29] grep: add tests for --threads=N and grep.threads

On Thu, May 11, 2017 at 8:36 PM, Brandon Williams wrote: > On 05/11, Ævar Arnfjörð Bjarmason wrote: >> 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

Re: [PATCH v4 2/4] diff: have the diff-* builtins configure diff before initializing revisions

On 2017-05-08 11:22 PM, Jeff King wrote: On Mon, May 08, 2017 at 12:03:37PM -0400, Marc Branchaud wrote: This matches how the diff Porcelain works. It makes the plumbing commands respect diff's configuration options, such as indentHeuristic, because init_revisions() calls diff_setup() which

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

Hi Stefan, On Thu, 11 May 2017, Stefan Beller wrote: > On Thu, May 11, 2017 at 6:48 AM, Johannes Schindelin > wrote: > > 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 >

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

Ævar Arnfjörð Bjarmason wrote: > Ævar Arnfjörð Bjarmason (2): > perf: add function to setup a fresh test repo > perf: add test showing exponential growth in path globbing > > t/perf/README| 1 + > t/perf/p0100-globbing.sh | 43 +++ >

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

Hi Stefan, On Thu, 11 May 2017, Stefan Beller wrote: > 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/ >

Re: [PATCH v3 2/3] read-tree -m: make error message for merging 0 trees less smart aleck

Hi, Jean-Noel Avila wrote: > Signed-off-by: Jean-Noel Avila > Signed-off-by: Jonathan Nieder Please remove my sign-off. I didn't write or carry this patch. If you want to acknowledge my contribution, you can use something like Helped-by, but it's not

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

Jeff King wrote: > On Wed, May 10, 2017 at 10:00:44AM -0700, Jonathan Nieder wrote: >> Jeff King wrote: >>> [1] The reachability checks from upload-pack don't actually do much on >>> GitHub, because you can generally access the objects via the API or >>> the web site anyway. [...] >>

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

Hi there, 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 I’m issuing `git config --show-origin --get user.email` against an directory which hasn’t been `git init`ed I get the

Re: [PATCH 08/29] grep: add tests for --threads=N and grep.threads

On 05/11, Ævar Arnfjörð Bjarmason wrote: > 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

Re: [PATCH 07/29] grep: change non-ASCII -i test to stop using --debug

On Thu, May 11, 2017 at 8:31 PM, Brandon Williams wrote: > On 05/11, Ęvar Arnfjörš Bjarmason wrote: >> 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

Re: [PATCH 07/29] grep: change non-ASCII -i test to stop using --debug

On 05/11, Ævar Arnfjörð Bjarmason wrote: > 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

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

On Thu, May 11, 2017 at 6:48 AM, Johannes Schindelin wrote: > 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

Re: [PATCH] pull: optionally rebase submodules

On Thu, May 11, 2017 at 10:24 AM, Brandon Williams wrote: > 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. > >

[PATCH/RFC 5/6] grep: support regex patterns containing \0 via PCRE v2

Support regex patterns with embedded \0's, as an earlier commit[1] notes this was previously impossible due to an internal limitation. Before this change any regex metacharacters in patterns containing \0 were silently ignored and the pattern matched as if it were a --fixed-strings pattern. Now

[PATCH/RFC 2/6] Makefile & compat/pcre2: add dependency on pcre2_convert.c

Add a dependency on the experimental pcre2_convert.c. This only exists in svn trunk of pcre2 currently, and allows for converting POSIX basic/extended & glob patterns to patterns accepted by PCRE[1][2]. 1. https://bugs.exim.org/show_bug.cgi?id=2106 2. https://bugs.exim.org/show_bug.cgi?id=2107

[PATCH/RFC 6/6] grep: use PCRE v2 under the hood for -G & -E for amazing speedup

Change the underlying engine powering POSIX basic & extended patterns to be PCRE v2 under the hood. This relies on an experimental SVN-trunk only PCRE v2 API which Philip Hazel (the PCRE maintainer) wrote up in response to a feature request I filed1[1]. This allows us to use

[PATCH/RFC 4/6] test-lib: add LIBPCRE1 & LIBPCRE2 prerequisites

Add LIBPCRE1 and LIBPCRE2 prerequisites which are true when git is compiled with USE_LIBPCRE1=YesPlease or USE_LIBPCRE2=YesPlease, respectively. There are various edge cases or version-specific features that need to be tested for. Signed-off-by: Ævar Arnfjörð Bjarmason ---

[PATCH/RFC 1/6] Makefile & compat/pcre2: add ability to build an embedded PCRE

Add a USE_LIBPCRE2_BUNDLED=YesIHaveNoPackagedVersion flag to the Makefile which'll use the PCRE v2 shipped in compat/pcre2 instead of trying to find it via -lpcre2-8 on the installed system. As covered in a previous commits ("grep: add support for PCRE v2", 2017-04-08) there are major benefits to

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

Thanks for your suggestions. I'll hold off on sending out a new patch (following Jonathan Nieder's suggestions [1]) until we decide if further optimizations (for example, as suggested by Peff) need to be done. [1] <20170510232231.gc28...@aiede.svl.corp.google.com> On 05/11/2017 02:46 AM, Jeff

[PATCH/RFC 0/6] Speed up git-grep by using PCRE v2 as a backend

Thought I'd send this to the list too. This is first of my WIP post-PCRE v2 inclusion series's. In addition to the huge speed improvements for grep -P noted in the culmination of that series[1], this speeds up all other types of grep invocations (fixed string & POSIX basic/extended) by using an

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

On 05/11, Junio C Hamano wrote: > Brandon Williams writes: > > > ls-files is the only command (that I know of) which does cache pruning > > based on the common prefix of all pathspecs given. If there is a > > submodule named 'sub' and you provided a pathspec 'sub/', the

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

[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

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

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

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

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

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

[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! >

  1   2   >