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 mak
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, a
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 m
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.
The earlier "grep: change the internal PCRE macro names to be PCRE1"
change elaborates on the motivations behind this commit.
Make the pattern types "pcre" & "pcre1" synonyms for the long-standing
"perl" grep.patternType.
This change is part of a longer patch series to add pcre2 support to
Git. It's nice to be able to performance test PCRE v1 v.s. v2 without
having to recompile git, and doing that via grep.patternType ma
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.
When JIT support is enabled the PCRE performance usually improves by
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-ish, pretty much every function is either renamed or takes
different arguments. Thus using it via entirely new functions m
Change the USE_LIBPCRE=YesPlease & --with-libpcre flags to the
Makefile & configure script, respectively, to mean use PCRE v2, not
PCRE v1. The legacy library is still available on request via
USE_LIBPCRE1=YesPlease or --with-libpcre1.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Makefile | 21
Remove the support for concurrently using PCRE v1 & v2 by compiling
Git with support for both.
Having access to both at runtime via grep.patternType=[pcre1|pcre2]
makes it easier for the developer hacking on the PCRE implementations
to test them concurrently, but adds confusion for everyone else,
I also wanted to include Linus' sha1 in our software at work.
But the GPLv2 license was incompatible.
Too bad it is just just in the public domain.
I grabbed Steve Reid's public domain code from 1999
and ran it. It produced the same output.
I ran it on a 3GB input file, and Linus' code from 2009 ta
A Phádraig, cá bhfuil tú i do chónaí?
Tá mé i gCalafoirne.
--
View this message in context:
http://git.661346.n2.nabble.com/Linus-sha1-is-much-faster-tp3448007p7657474.html
Sent from the git mailing list archive at Nabble.com.
Hi Peff,
On Thu, 20 Apr 2017, Jeff King wrote:
> On Thu, Apr 20, 2017 at 04:41:18PM -0400, David Turner wrote:
>
> > When core.packedGitLimit is exceeded, git will close packs. If there
> > is a repack operation going on in parallel with a fetch, the fetch
> > might open a pack, and then be for
As a refresh of everyone's memory (because mine needed it). This is a
feature I added back in 2011 when the i18n support was initially
added.
There was concern at the time that we would inadvertently mark
plumbing messages for translation, particularly something in a shared
code path, and this was
> -Original Message-
> From: Johannes Schindelin [mailto:johannes.schinde...@gmx.de]
> Sent: Thursday, April 20, 2017 5:58 PM
> To: Jeff King
> Cc: David Turner ; git@vger.kernel.org
> Subject: Re: [PATCH] Increase core.packedGitLimit
>
> Hi Peff,
>
> On Thu, 20 Apr 2017, Jeff King wrot
On 04/11, Stefan Beller wrote:
> +int has_submodules(unsigned what_to_check)
> +{
> + if (what_to_check & SUBMODULE_CHECK_ANY_CONFIG) {
> + if (submodule_config_reading == SUBMODULE_CONFIG_NOT_READ)
> + load_submodule_config();
> + if (submodule_confi
On 04/11, Stefan Beller wrote:
> The commit 31224cbdc7 (clone: recursive and reference option triggers
> submodule alternates, 2016-08-17) argued for any further `submodule update`
> to respect the initial setup. This is not the case if you only pass
> '--reference[-if-able]' to the initial clone w
On 04/20, Ævar Arnfjörð Bjarmason wrote:
> Change two case statements added in commit 0281e487fd ("grep:
> optionally recurse into submodules", 2016-12-16) so that they die if
> new GREP_PATTERN_* enum fields are added without updating them.
>
> These case statements currently check for an exhaust
On Thu, Apr 20, 2017 at 3:07 PM, Brandon Williams wrote:
> On 04/11, Stefan Beller wrote:
>> +int has_submodules(unsigned what_to_check)
>> +{
>> + if (what_to_check & SUBMODULE_CHECK_ANY_CONFIG) {
>> + if (submodule_config_reading == SUBMODULE_CONFIG_NOT_READ)
>> +
On 04/20, Ævar Arnfjörð Bjarmason wrote:
> Amend the submodule recursion test added in commit 0281e487fd ("grep:
> optionally recurse into submodules", 2016-12-16) to prepare it for
> subsequent tests of whether it passes along the grep.patternType to
> the submodule greps.
>
> This is just the re
On 04/20, Stefan Beller wrote:
> On Thu, Apr 20, 2017 at 3:07 PM, Brandon Williams wrote:
> > On 04/11, Stefan Beller wrote:
> >> +int has_submodules(unsigned what_to_check)
> >> +{
> >> + if (what_to_check & SUBMODULE_CHECK_ANY_CONFIG) {
> >> + if (submodule_config_reading == SUBM
On Thu, Apr 20, 2017 at 03:20:16PM -0700, Brandon Williams wrote:
> On 04/20, Ævar Arnfjörð Bjarmason wrote:
> > Change two case statements added in commit 0281e487fd ("grep:
> > optionally recurse into submodules", 2016-12-16) so that they die if
> > new GREP_PATTERN_* enum fields are added witho
On Thu, Apr 20, 2017 at 3:12 PM, Brandon Williams wrote:
> On 04/11, Stefan Beller wrote:
>> The commit 31224cbdc7 (clone: recursive and reference option triggers
>> submodule alternates, 2016-08-17) argued for any further `submodule update`
>> to respect the initial setup. This is not the case if
Duy Nguyen writes:
> Looking good. I would add some comment, lest ';' feel lonely. But it's
> really personal taste.
... which matches mine. Thanks for the update (which I'll squash in).
>
> -- 8< --
> diff --git a/builtin/worktree.c b/builtin/worktree.c
> index 5ebdcce793..bc75676bf3 100644
Jeff King writes:
>> if (!ret && opts->keep_locked)
>> -;
>> +; /* --lock wants to keep "locked" file */
>> else
>> unlink_or_warn(sb.buf);
>
> I know this is just a drive-by comment, but given that the "else" is the
> only thing that doe
Lars Schneider writes:
> Sorry for sending this email multiple times. My mobile email client created
> html... Should be fixed now!
>
>>
>> * ls/filter-process-delayed (2017-03-06) 1 commit
>> - convert: add "status=delayed" to filter process protocol
>>
>> What's the status of this one???
>>
Lars Schneider writes:
>> * bw/forking-and-threading (2017-04-19) 11 commits
>> - run-command: block signals between fork and execve
>> - run-command: add note about forking and threading
>> - run-command: handle dup2 and close errors in child
>> - run-command: eliminate calls to error handling f
On 04/20, Brandon Williams wrote:
> On 04/20, Johannes Schindelin wrote:
> > Hi Lars & Junio,
> >
> > On Thu, 20 Apr 2017, Lars Schneider wrote:
> >
> > > > * bw/forking-and-threading (2017-04-19) 11 commits
> > > > - run-command: block signals between fork and execve
> > > > - run-command: add n
SZEDER Gábor writes:
> We had two similar bugs in the tests sporadically triggering error
> messages during the removal of the trash directory, see commits
> bb05510e5 (t5510: run auto-gc in the foreground, 2016-05-01) and
> ef09036cf (t6500: wait for detached auto gc at the end of the test
> scr
Brandon Williams writes:
> On 04/20, Brandon Williams wrote:
>> On 04/20, Johannes Schindelin wrote:
>> > Hi Lars & Junio,
>> >
>> > On Thu, 20 Apr 2017, Lars Schneider wrote:
>> >
>> > > > * bw/forking-and-threading (2017-04-19) 11 commits
>> > > > - run-command: block signals between fork and
Stefan Beller writes:
> + Junio
Just like Michael, I do not have strong enough opinion for or
against this patch to comment on it.
I do agree with you that it would be a good longer-term direction to
use "submodule" for a "struct submodule" (i.e. submodule object),
and call a string that names
Jeff King writes:
> - this patch probably adds "unsorted tree" to the list of breakages
> that would cause us to skip rename detection. I don't know if that's
> actually possible in practice (i.e., do we end up sorting the
> diffq elsewhere anyway?). I also wondered if it might run
Nguyễn Thái Ngọc Duy writes:
> Some of you may recall a while back, nd/conditional-config-include
> failed on Windows because I accidentally fopen()'d a directory in a
> test, but it's not considered an serious error unless it's on Windows,
> where fopen() returns NULL.
>
> A couple of suggestio
Nguyễn Thái Ngọc Duy writes:
> This function is later used by "worktree move" and "worktree remove"
> to ensure that we have a good connection between the repository and
> the worktree. For example, if a worktree is moved manually, the
> worktree location recorded in $GIT_DIR/worktrees/.../gitdi
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> worktree.c | 21 +
> worktree.h | 6 ++
> 2 files changed, 27 insertions(+)
>
> diff --git a/worktree.c b/worktree.c
> index 40cc031ac9..c695dcf982 100644
> --- a/worktree.c
> +++ b/worktree.c
>
Nguyễn Thái Ngọc Duy writes:
> There are two options to move the main worktree, but both have
> complications, so it's not implemented yet. Anyway the options are:
>
> - convert the main worktree to a linked one and move it away, leave the
>git repository where it is. The repo essentially b
Nguyễn Thái Ngọc Duy writes:
> Similar to "mv a b/", which is actually "mv a b/a", we extract basename
> of source worktree and create a directory of the same name at
> destination if dst path is a directory.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/worktree.c | 19 +
Nguyễn Thái Ngọc Duy writes:
> Submodules contains .git files with relative paths. After a worktree
> move, these files need to be updated or they may point to nowhere.
>
> This is a bandage patch to make sure "worktree move" don't break
> people's worktrees by accident. When .git file update co
Nguyễn Thái Ngọc Duy writes:
> + worktrees = get_worktrees(0);
> + wt = find_worktree(worktrees, prefix, av[0]);
> + if (!wt)
> + die(_("'%s' is not a working directory"), av[0]);
> + if (is_main_worktree(wt))
> + die(_("'%s' is a main working directory"),
Junio C Hamano writes:
> I wonder if it is OK to only special case ENOENT for !fp cases,
> where existing code silently returns. Perhaps it is trying to read
> an optional file, and it returns silently because lack of it is
> perfectly OK for the purpose of the code. Are there cases where
> thi
Christian Couder writes:
> Could you try with the following patch:
>
> http://public-inbox.org/git/20170330210354.20018-1-chrisc...@tuxfamily.org/
Ah, this reminds me. The patch has been in the stalled state for
quite some time due to confusing description. How about explaining
it like so and
All patches in the series looked sensible. Thanks.
I think I meant to write "big pidfiles" there.
With xsize_t() gc would die when seeing a pidfile whose size doesn't fit into
size_t. The version I sent just ignores such files. However, it would choke
on slightly smaller files that happen to not fit into memory. And no
reasonable pidfile can
Jeff King writes:
> When we complete branch names for "git checkout", we also
> complete remote branch names that could trigger the DWIM
> behavior. Depending on your workflow and project, this can
> be either convenient or annoying.
> ...
> This is flexible enough for me, but it's possible someb
On Thu, Apr 20, 2017 at 10:01:32PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > When we complete branch names for "git checkout", we also
> > complete remote branch names that could trigger the DWIM
> > behavior. Depending on your workflow and project, this can
> > be either convenient
Jeff King writes:
> ... But I think it's really the
> completion that bugs me. The DWIM is easy to avoid triggering if you
> just don't feed it the remote branch names. It's the completion that
> routinely leads me to doing that. :)
True.
Johannes Schindelin writes:
> Note: while the `time_t` data type exists and is meant to be used for
> timestamps, on 32-bit Linux it is *still* 32-bit. An earlier iteration
> used `time_t` for that reason, but it came with a few serious downsides:
> as `time_t` can be signed (and indeed, on Windo
On Thu, Apr 20, 2017 at 08:41:32PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > I wonder if it is OK to only special case ENOENT for !fp cases,
> > where existing code silently returns. Perhaps it is trying to read
> > an optional file, and it returns silently because lack of it
On Thu, Apr 20, 2017 at 06:25:59PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/log.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index b3b10cc1ed..26d6a3cf14 100644
> --- a/builtin/log.c
On 04/21/2017 03:12 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> + Junio
>
> Just like Michael, I do not have strong enough opinion for or
> against this patch to comment on it.
>
> I do agree with you that it would be a good longer-term direction to
> use "submodule" for a "struct su
On 04/21/2017 08:32 AM, Michael Haggerty wrote:
> [...]
> I've CCed Duy because I don't know whether he has more plans regarding
> submodule references [...] get rid of the
> `for_each_ref_submodule()` family of functions entirely.
>
> So perhaps the code that this patch touches won't be around lo
101 - 150 of 150 matches
Mail list logo
