On Fri, Jul 26, 2019 at 1:11 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > diff --git a/cache-tree.c b/cache-tree.c
> > index 706ffcf188..99144b1704 100644
> > --- a/cache-tree.c
> > +++ b/cache-tree.c
> > @@ -613,14 +613,19 @@ int write_index_as_tree(struct object_id *oid, struct
> >
On Fri, Jul 26, 2019 at 12:57 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Alternatively, you can view this as "make the merge functions behave
> > more similarly." merge-recursive has three different entry points:
> > merge_trees(), merge_recursive(), and merge_recursive_generic().
On Fri, Jul 26, 2019 at 12:32 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Make sure we do the index == head check at the beginning of the merge,
> > and error out immediately if it fails. While we're at it, fix a small
> > leak in the show-the-error codepath.
>
> As the call to repo
On Fri, Jul 26, 2019 at 12:15 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > ...
> > So, load the index in builtin/merge-recursive.c, reload the in-memory
> > index in builtin/stash.c, and modify the t3030 testcase to correctly
> > setup the index and make sure that the test fails in th
On Fri, Jul 26, 2019 at 11:31 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > Returning before freeing the allocated buffer is suboptimal; as with
> > elsewhere in the same function, make sure buf gets free'd.
>
> I do not have a real objection to the patch text, but the above
> justific
Hi all,
As mentioned during the standup in #git-devel today, we encountered a
BUG() during certain circumstances of a criss-cross merge. Timing has
prevented me from getting the repro case together to send just yet, but
it appears that the issue is as follows:
- During a merge in a repo with fai
On 2019.07.26 14:12, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 26 Jul 2019, SZEDER Gábor wrote:
>
> > On Wed, Jul 24, 2019 at 04:06:50PM -0700, Josh Steadmon wrote:
> >
> > > 3: acf3aebcaa ! 3: a07458b2e4 ci: run trace2 schema validation in the
> > > CI suite
> > > @@ ci/run-build-and-t
Robin Kuzmin writes:
> At this page (in Russian)
>
> https://git-scm.com/book/ru/v2/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-Git-%D0%9F%D0%BE%D0%B4%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B8
> I see:
> вы рассмотрим
> I expected:
> мы рассмотрим
> And I fail to fin
On Fri, Jul 26 2019, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jul 26 2019, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> diff --git a/Makefile b/Makefile
>>> index bd246f2989..dd38d5e527 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -726,6 +726,7 @@ TEST_BUILTINS_OBJS
On Fri, Jul 26 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> diff --git a/grep.c b/grep.c
>> index 6d60e2e557..5bc0f4f32a 100644
>> --- a/grep.c
>> +++ b/grep.c
>> @@ -615,6 +615,16 @@ static void compile_regexp(struct grep_pat *p, struct
>> grep_opt *opt)
>>
On Fri, Jul 26 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> diff --git a/Makefile b/Makefile
>> index bd246f2989..dd38d5e527 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -726,6 +726,7 @@ TEST_BUILTINS_OBJS += test-oidmap.o
>> TEST_BUILTINS_OBJS += test-online-cpus.o
Hi Stolee,
On Fri, Jul 26, 2019 at 09:18:50AM -0400, Derrick Stolee wrote:
> On 7/25/2019 11:18 PM, Taylor Blau wrote:
> > Hi everybody,
> >
> > Pushes to forks of git.git hosted on GitHub now advertise the tips of
> > git.git as well as branches from your fork.
> >
> > You may recall that Peff an
On 2019.07.25 09:14, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >> I would appreciate any feedback on better ways to integrate the
> >> validator into the CI suite.
> >
> > How about adding a test script dedicated to JSON schema validation,
> > which runs only as many git commands as needed
At this page (in Russian)
https://git-scm.com/book/ru/v2/%D0%98%D0%BD%D1%81%D1%82%D1%80%D1%83%D0%BC%D0%B5%D0%BD%D1%82%D1%8B-Git-%D0%9F%D0%BE%D0%B4%D0%BC%D0%BE%D0%B4%D1%83%D0%BB%D0%B8
I see:
вы рассмотрим
I expected:
мы рассмотрим
And I fail to find the exact file to fix. I fail to find
On 2019-07-26 at 14:01:03, Johannes Schindelin wrote:
> Actually, the part that uses it is not shown in the patch (one of the
> many, many reasons why I try to discourage patch review and encourage
> code review instead). The relevant section currently looks somewhat like
> this:
I feel like I may
Ævar Arnfjörð Bjarmason writes:
> diff --git a/Makefile b/Makefile
> index bd246f2989..dd38d5e527 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -726,6 +726,7 @@ TEST_BUILTINS_OBJS += test-oidmap.o
> TEST_BUILTINS_OBJS += test-online-cpus.o
> TEST_BUILTINS_OBJS += test-parse-options.o
> TEST_B
Hi everyone!
As I see it, in Junio's approach you more likely to have a translation and
original out of sync because you have to figure out whether the changes in the
original are actually reflected in the translation, which could be a tedious
thing to do again and again.
In the approach that
Ævar Arnfjörð Bjarmason writes:
> When grepping a non-ASCII fixed string. This is a more general problem
> that's hard to fix, but we can at least fix the most common case of
> grepping for a fixed string without "-i". I can't think of a reason
> for why we'd turn on PCRE2_UTF when matching byte
Ævar Arnfjörð Bjarmason writes:
> diff --git a/grep.c b/grep.c
> index 6d60e2e557..5bc0f4f32a 100644
> --- a/grep.c
> +++ b/grep.c
> @@ -615,6 +615,16 @@ static void compile_regexp(struct grep_pat *p, struct
> grep_opt *opt)
> die(_("given pattern contains NULL byte (via -f ). Thi
e87de7cab4 ("grep: un-break building with PCRE < 8.32", 2017-05-25)
added a restriction for JIT support that is no longer needed after
pcre_jit_exec() calls were removed.
Reorganize the definitions in grep.h so that JIT support could be
detected early and NO_LIBPCRE1_JIT could be used reliably to
Johannes Schindelin writes:
> Hi Junio,
>
> On Thu, 25 Jul 2019, Junio C Hamano wrote:
>
>> The seventh batch is in; I've merged fix-up topics that has been in
>> 'master' for some time (i.e. up to the third batch of this cycle)
>> down to 'maint'.
>
> Would you terribly mind also merging `js/gcc
The code used both a macro and a variable to keep track if JIT
support was desired and relied on the fact that a non JIT
enabled library will ignore a request for JIT compilation
(as defined by the second parameter of the call to pcre_study)
Cleanup the multiple levels of macros used and call pcre
Sent as an RFC since it was meant to be applied against ab/pcre-jit-fixes
but that is likely to change with the reroll of that branch.
[PATCH 1/2] grep: make sure NO_LIBPCRE1_JIT disable JIT in PCRE1
[PATCH 2/2] grep: refactor and simplify PCRE1 support
The end result could be squashed together
Hello,
I'm running git for windows installed locally. Windows 10 Pro version
1903 OS Build 18362.239. I have a repository on a UNIX machine running AIX 7.1
TL4 SP2. I use SAMBA 3.0.23d to mount the drive for use. I upgraded to git 2.22
and am having issues. Even starting from a fresh clo
Ævar Arnfjörð Bjarmason writes:
> 1-3 here are a re-roll on "next". I figured that was easier for
> everyone with the state of the in-flight patches, it certainly was for
> me. Sorry Junio if this creates a mess for you.
As long as I can just apply all of them on top of no-kwset and keep
it a s
Elijah Newren writes:
> diff --git a/cache-tree.c b/cache-tree.c
> index 706ffcf188..99144b1704 100644
> --- a/cache-tree.c
> +++ b/cache-tree.c
> @@ -613,14 +613,19 @@ int write_index_as_tree(struct object_id *oid, struct
> index_state *index_state,
> int entries, was_valid;
> struc
On Fri, Jul 26 2019, Carlo Arenas wrote:
> On Fri, Jul 26, 2019 at 8:15 AM Ævar Arnfjörð Bjarmason
> wrote:
>> I'm not sure what a real fix for that is. Part of it is probably 8/8 in
>> the series I mention below, but more generally we'd need to be more
>> encoding aware at a much higher callsi
Elijah Newren writes:
> Alternatively, you can view this as "make the merge functions behave
> more similarly." merge-recursive has three different entry points:
> merge_trees(), merge_recursive(), and merge_recursive_generic(). Two of
> these would call diff_warn_rename_limit(), but merge_tree
On Tue, Apr 23, 2019 at 10:30:56AM -0700, Elijah Newren wrote:
> diff --git a/builtin/pack-refs.c b/builtin/pack-refs.c
> index f3353564f9..cfbd5c36c7 100644
> --- a/builtin/pack-refs.c
> +++ b/builtin/pack-refs.c
> @@ -1,4 +1,5 @@
> #include "builtin.h"
> +#include "config.h"
> #include "parse-
Elijah Newren writes:
> Make sure we do the index == head check at the beginning of the merge,
> and error out immediately if it fails. While we're at it, fix a small
> leak in the show-the-error codepath.
As the call to repo_index_has_changes() is moved to the very
beginning of merge_recursive
On Fri, Jul 26 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> FWIW what I meant was not that we'd run around and iconv() things, it
>> wouldn't make much sense to e.g. iconv() some PNG data to be "UTF-8
>> valid", which presumably would be the end result of something like th
Elijah Newren writes:
> merge_trees() took a results parameter that would only be written when
> opt->call_depth was positive, which is never the case now that
> merge_trees_internal() has been split from merge_trees(). Remove the
> misleading and unused parameter from merge_trees().
>
> While a
Elijah Newren writes:
> ...
> So, load the index in builtin/merge-recursive.c, reload the in-memory
> index in builtin/stash.c, and modify the t3030 testcase to correctly
> setup the index and make sure that the test fails in the expected way
> (meaning it reports a rename/rename conflict).
The
I am building some CI tooling, and I am working with a large-ish repository, so
I am trying to start with a shallow clone of the repository and deepen it on
demand. I am finding it very difficult to correctly switch between fetch
--depth and fetch --deepen.
I am looking for a way to "recover" from
Elijah Newren writes:
> Commit d7cf3a96e9a0 ("merge-recursive.c: remove implicit dependency on
> the_repository", 2019-01-12) and follow-ups like commit 34e7771bc644
> ("Use the right 'struct repository' instead of the_repository",
> 2019-06-27), removed most implicit uses of the_repository. Con
Elijah Newren writes:
> Returning before freeing the allocated buffer is suboptimal; as with
> elsewhere in the same function, make sure buf gets free'd.
I do not have a real objection to the patch text, but the above
justification does not make much sense to me. The original code
returned an e
Varun Naik writes:
> It is possible to delete a committed file from the index and then add it
> as intent-to-add. After `git reset HEAD`, the file should be identical
> in the index and HEAD. This patch provides the desired behavior even
> when the file is empty in the index.
The first and the s
While investigating improvements to clone performance at GitLab we've
been looking at how to trigger packfile reuse during clones. A challenge
of the investigation and a future challenge of rolling out changes to
encourage more frequent packfile reuse is knowing when packfile reuse
kicks in and
Hello My Dear,
We write to let you know that your package is due to be deliver to you
and we can not afford to keep the package in this office any longer.
You need to understand that your package is here to be deliver to you,
not to be dope here without proper arrangement on how to get it to
you.
Ævar Arnfjörð Bjarmason writes:
> FWIW what I meant was not that we'd run around and iconv() things, it
> wouldn't make much sense to e.g. iconv() some PNG data to be "UTF-8
> valid", which presumably would be the end result of something like that.
>
> Rather that this model of assuming that a UT
On Fri, Jul 26, 2019 at 8:15 AM Ævar Arnfjörð Bjarmason
wrote:
> I'm not sure what a real fix for that is. Part of it is probably 8/8 in
> the series I mention below, but more generally we'd need to be more
> encoding aware at a much higher callsite than "grep". So e.g. we'd know
> that we match "
This is the bug that just won't die; there always seems to be another
form of it somewhere. See the commit message of 55f39cf7551b ("merge:
fix misleading pre-merge check documentation", 2018-06-30) for a more
detailed explanation), but in short:
builtin/merge.c contains this important requirem
merge_trees() took a results parameter that would only be written when
opt->call_depth was positive, which is never the case now that
merge_trees_internal() has been split from merge_trees(). Remove the
misleading and unused parameter from merge_trees().
While at it, add some comments explaining
No substantive code changes (view this with diff --color-moved), but
a few small code cleanups:
* Move structs and an inline function only used by merge-recursive.c
into merge-recursive.c
* Re-order function declarations to be more logical
* Add or fix some explanatory comments
Signed-of
write_tree_from_memory() appeared to be a merge-recursive special that
basically duplicated write_index_as_tree(). The two had a slightly
different call structure but the big difference was just that
write_index_as_tree() would always unconditionally read the index off of
disk instead of working o
We provided users with the ability to state whether they wanted rename
detection, and to put a limit on how much CPU would be spent. Both of
these fields had multiple configuration parameters for setting them,
with one being a fallback and the other being an override. However,
instead of implemen
It is not at all clear what 'mr' was supposed to stand for, at least not
to me. Pick a clearer name for this variable.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 8114e7
In commit 259ccb6cc324 ("merge-recursive: rename merge_options argument
from 'o' to 'opt'", 2019-04-05), I renamed a bunch of function
arguments in merge-recursive.c, but forgot to make that same change to
merge-recursive.h. Make the two match.
Signed-off-by: Elijah Newren
---
merge-recursive.h
No substantive code change, just add some line breaks to fix lines that
have grown in length due to various refactorings. Most remaining lines
of excessive length in merge-recursive include error messages and it's
not clear that splitting those improves things.
Signed-off-by: Elijah Newren
---
In commit 7ca56aa07619 ("merge-recursive: add a label for ancestor",
2010-03-20), a label was added for the '||' line to make it have
the more informative heading '|| merged common ancestors', with
the statement:
It would be nicer to use a more informative label. Perhaps someone
w
merge_options has several internal fields that should not be set or read
by external callers. This just complicates the API. Move them into an
opaque merge_options_internal struct that is defined only in
merge-recursive.c and keep these out of merge-recursive.h.
Signed-off-by: Elijah Newren
---
I want to implement the same outward facing API as found within
merge-recursive.h in a different merge strategy. However, that makes
names like MERGE_RECURSIVE_{NORMAL,OURS,THEIRS} look a little funny;
rename to MERGE_VARIANT_{NORMAL,OURS,THEIRS}.
Signed-off-by: Elijah Newren
---
merge-recursiv
Other than cache.h which needs to appear first, and merge-recursive.h
which I want to be second so that we are more likely to notice if
merge-recursive.h has any missing includes, the rest of the list is
long and easier to look through if it's alphabetical.
Signed-off-by: Elijah Newren
---
merge
The merge_options struct had lots of fields, making it a little
imposing, but the options naturally fall into multiple different groups.
Grouping similar options and adding a comment or two makes it easier to
read, easier for new folks to figure out which options are related, and
thus easier for th
If opt->buffer_output is less than 2, then merge_trees(),
merge_recursive(), and merge_recursive_generic() are all supposed to
flush the opt->obuf output buffer to stdout and release any memory it
holds. merge_trees() did not do this. Move the logic that handles this
for merge_recursive_internal(
In commit 8daec1df03de ("merge-recursive: switch from (oid,mode) pairs
to a diff_filespec", 2019-04-05), an assertion on a->path && b->path
was added for code readability to document that these both needed to be
non-NULL at this point in the code. However, the subsequent lines also
read o->path, s
merge_trees(), merge_recursive(), and merge_recursive_generic() in
their function headers used four different names for the merge base or
list of merge bases they were passed:
* 'common'
* 'ancestors'
* 'ca'
* 'base_list'
They were able to refer to it four different ways instead of only thr
Commit d7cf3a96e9a0 ("merge-recursive.c: remove implicit dependency on
the_repository", 2019-01-12) and follow-ups like commit 34e7771bc644
("Use the right 'struct repository' instead of the_repository",
2019-06-27), removed most implicit uses of the_repository. Convert
calls to get_commit_tree()
Returning before freeing the allocated buffer is suboptimal; as with
elsewhere in the same function, make sure buf gets free'd.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
ind
Alternatively, you can view this as "make the merge functions behave
more similarly." merge-recursive has three different entry points:
merge_trees(), merge_recursive(), and merge_recursive_generic(). Two of
these would call diff_warn_rename_limit(), but merge_trees() didn't.
This lead to callers
Before writing a replacement merge strategy for recursive, I decided
to first cleanup the merge API -- streamlining merge-recursive.h and
making it more readable. It includes some fixes I noticed along the
way, and two forgotten patches of mine from months ago that I rebased
and included at the en
We had a rule to enforce that the index matches head, but it was found
at the beginning of merge_trees() and would only trigger when
opt->call_depth was 0. Since merge_recursive() doesn't call
merge_trees() until after returning from recursing, this meant that the
check wasn't triggered by merge_r
Hi Dscho,
On Fri, Jul 26, 2019 at 4:25 AM Johannes Schindelin
wrote:
>
> On Thu, 25 Jul 2019, Elijah Newren wrote:
>
> > On Thu, Jul 25, 2019 at 1:12 PM Johannes Schindelin
> > wrote:
> > But, more importantly:
> > * I want to write an alternative merge strategy providing drop-in
> > replacem
Hi Dscho,
On Thu, Jul 25, 2019 at 12:15 PM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Thu, 25 Jul 2019, Elijah Newren wrote:
>
> > * All current callers (3 of them?) of merge_recursive() always pass
> > it a specially created reversed-list for the merge_bases. Some
> > history sp
On Thu, Jul 25 2019, Johannes Schindelin wrote:
> Hi Junio,
>
> On Thu, 25 Jul 2019, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> >> 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'
As discussed in the "grep: stess test PCRE v2 on invalid UTF-8 data"
commit leading up to this one there's a regression in
b65abcafc7 ("grep: use PCRE v2 for optimized fixed-string search",
2019-07-01) when matching UTF-8 data.
This ultimately isn't straightforward to just "fix", because the kwset
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 f002532784 ("grep: print
the pcre2_jit_on value", 20
Since my b65abcafc7 ("grep: use PCRE v2 for optimized fixed-string
search", 2019-07-01) we've been dying on invalid UTF-8 data when
grepping for fixed strings if the following are all true:
* The subject string is non-ASCII (e.g. "ævar")
* We're under a is_utf8_locale(), e.g. "en_US.UTF-8"
1-3 here are a re-roll on "next". I figured that was easier for
everyone with the state of the in-flight patches, it certainly was for
me. Sorry Junio if this creates a mess for you.
4-8 are a "fix" for the UTF-8 matching error noted in Carlo's "grep:
skip UTF8 checks explicitally" in
https://publ
At the start of this function we do:
p->fixed = opt->fixed;
It's less confusing to use that variable consistently that switch back
& forth between the two.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
grep.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/grep.c b/grep.c
As discussed in the last commit partially fix a bug introduced in
b65abcafc7 ("grep: use PCRE v2 for optimized fixed-string search",
2019-07-01). Because PCRE v2, unlike kwset, validates its UTF-8 input
we'd die on e.g.:
fatal: pcre2_match failed with error code -22: UTF-8 error:
isolated
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
This change paves the way for later using this value the regex compile
functions themselves.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
grep.c | 7 +++
grep.h | 1 +
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/grep.c b/grep.c
index b94e998680..6d60e2e557 100644
--- a/grep.
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
On Fri, Jul 26 2019, Carlo Arenas wrote:
> On Fri, Jul 26, 2019 at 6:50 AM Ævar Arnfjörð Bjarmason
> wrote:
>>
>> On Fri, Jul 26 2019, Carlo Arenas wrote:
>>
>> > since this moves PCRE1 out of the JIT fast path,
>>
>> I think you're mostly replying to the wrong thread. None of the patches
>> I'
Hi Junio,
On Thu, 25 Jul 2019, Junio C Hamano wrote:
> The seventh batch is in; I've merged fix-up topics that has been in
> 'master' for some time (i.e. up to the third batch of this cycle)
> down to 'maint'.
Would you terribly mind also merging `js/gcc-8-and-9` into `maint`?
Otherwise, the CI
--
Thanks for your last email response to me.
The information required should include the following-:
Your full names
Your address
Telephone number
Your private email
Occupation
AgeThis is to enable my further discussion with you in confidence.
Best regards and wishes to you.
Philip Twite
REPLY
On Fri, Jul 26, 2019 at 6:50 AM Ævar Arnfjörð Bjarmason
wrote:
>
> On Fri, Jul 26 2019, Carlo Arenas wrote:
>
> > since this moves PCRE1 out of the JIT fast path,
>
> I think you're mostly replying to the wrong thread. None of the patches
> I've sent disable PCRE v1 JIT, as the performance numbers
Hi Junio,
On Thu, 25 Jul 2019, Junio C Hamano wrote:
> Elijah Newren writes:
>
> > On Thu, Jul 25, 2019 at 11:12 AM Junio C Hamano wrote:
> >
> >> > Stuff I'd most welcome review on:
> >> > * Is cache-tree.c the right place for write_tree_from_memory()?
> >> > [see patch 7] Should there
Hi brian,
On Fri, 26 Jul 2019, brian m. carlson wrote:
> On 2019-07-25 at 10:11:22, Johannes Schindelin via GitGitGadget wrote:
> > From: Johannes Schindelin
> >
> > The format of the todo list is quite a bit different in the
> > `--rebase-merges` mode; Let's prepare the fake editor to handle th
On Fri, Jul 26, 2019 at 02:12:39PM +0200, Johannes Schindelin wrote:
> I was wary about this patch series ever since I got aware that it
> refuses to use an already-available JSON schema validator (such as
> `ajv`, a seemingly well-established all-purpose validator that even
> claims to be the fast
On Fri, Jul 26 2019, Carlo Arenas wrote:
> since this moves PCRE1 out of the JIT fast path,
I think you're mostly replying to the wrong thread. None of the patches
I've sent disable PCRE v1 JIT, as the performance numbers show. The JIT
stack is resized, and for v2 some dead code removed.
> int
On 7/25/2019 11:18 PM, Taylor Blau wrote:
> Hi everybody,
>
> Pushes to forks of git.git hosted on GitHub now advertise the tips of
> git.git as well as branches from your fork.
>
> You may recall that Peff and I have sent a handful of patches to allow
> repositories to customize how they gather
since this moves PCRE1 out of the JIT fast path, introduces the
regression where git grep will abort if there is binary data or non
UTF-8 text in the repository/log and should be IMHO hold out until a
fix for that can be merged.
this also needs additional changes to better support NO_LIBPCRE1_JIT,
Hi,
On Fri, 26 Jul 2019, SZEDER Gábor wrote:
> On Wed, Jul 24, 2019 at 04:06:50PM -0700, Josh Steadmon wrote:
>
> > 3: acf3aebcaa ! 3: a07458b2e4 ci: run trace2 schema validation in the CI
> > suite
> > @@ ci/run-build-and-tests.sh: then
> > make test
> > + t/trace_sc
Hi Elijah,
On Thu, 25 Jul 2019, Elijah Newren wrote:
> On Thu, Jul 25, 2019 at 1:12 PM Johannes Schindelin
> wrote:
> >
> > Hi Elijah,
> >
> > On Thu, 25 Jul 2019, Elijah Newren wrote:
> >
> > > merge_options has several internal fields that should not be set or read
> > > by external callers.
Hi Elijah,
On Thu, 25 Jul 2019, Elijah Newren wrote:
> On Thu, Jul 25, 2019 at 12:41 PM Johannes Schindelin
> wrote:
> >
> > On Thu, 25 Jul 2019, Elijah Newren wrote:
> >
> > > diff --git a/builtin/merge-recursive.c b/builtin/merge-recursive.c
> > > index 5b910e351e..a4bfd8fc51 100644
> > > ---
On Thu, Jul 25, 2019 at 09:56:45PM -0700, Varun Naik wrote:
> It is possible to delete a committed file from the index and then add it
> as intent-to-add. After `git checkout HEAD` or `git restore --staged`,
> the file should be identical in the index and HEAD. This patch provides
> the desired be
On 2019-07-25 at 10:11:14, Johannes Schindelin via GitGitGadget wrote:
> This is the most notable shortcoming that --rebase-merges has, still,
> relative to --preserve-merges' capabilities: it does not support passing
> custom merge strategies or custom merge strategy options.
>
> Let's fix this.
On 2019-07-25 at 10:11:22, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> The format of the todo list is quite a bit different in the
> `--rebase-merges` mode; Let's prepare the fake editor to handle those
> todo lists properly, too.
>
> Signed-off-by: Johannes Schin
90 matches
Mail list logo
